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The  Department  of  Defense  supports  the  use  of  electronic  data  interchange  (EDI)  and  the  eventual  move  to  a  global  EDI  standard.  DoD  is  committed  to 
working  with  the  standards-making  bodies,  other  agencies,  and  industry  to  make  that  end  a  reality.  The  issue  for  DoD  to  resolve  is  which  EDI  standard  to  use.  In 
the  early  stages  of  its  electronic  commerce  program,  DoD  adopted  the  use  of  Acredited  Standards  Committee  (ASC  XI 2)  EDI  standards  for  exchan^g  routine 
business  information  both  internally  and  externally.  A  current  worldwide  trend  to  use  UN/EDIFACT  EDI  standards  suggests  that  a  practical  DoD  policy  ovct  me 
long  term  would  be  to  suppport  United  Nation/Electronic  Data  Interchange  for  Administraton,  Commerce  and  Trade  (UN/EDIFACT)  as  a  single  worldwide 
standard. 

We  examined  four  areas:  trading  partners,  systems,  infiastiucture  and  woridoad.  We  found  DoD  to  be  progressing  toward  the  insertion  of  EDI  technology  to 
support  the  routine  exchange  of  business  information.  DoD  must  now  define  its  EDI  strategy  for  the  future  and  align  that  strategy  with  emerging  Federal  policy  on 
the  use  of  EDI  in  the  Federal  procurement  process.  This  report  discusses  DoD’s  readiness  to  migrate  to  UN/EDIFACT,  compares  ASC  X12  and  UN/EDIFACT, 
and  provides  recommendations  and  a  strategic  direction  for  migration. 
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Logistics  Management  Institute 

Department  of  Defense  Use  of  UN/EDIFACT  Standards: 

A  Readiness  Study  and  Migration  Strategy 

Executive  Summary 


A  recent  executive  memorandum^  charted  an  ambitious  schedule  to  imple¬ 
ment  electronic  data  interchange  (EDI)  in  the  Federal  procurement  process.  That 
memorandum  articulated  a  role  for  EDI  and  demonstrated  a  clear  commitment 
to  its  use. 

The  Department  of  Defense  has  consistently  supported  the  use  of  EDI  and 
the  eventual  move  to  a  global  electronic  data  interch^ge  standard.  DoD  is  com¬ 
mitted  to  working  with  the  standards-making  bodies,  other  government  agen¬ 
cies,  and  the  private  sector  to  make  that  end  a  reality.  The  issue  for  DoD  to 
resolve  is  which  EDI  standard  to  use. 

Today,  two  predominant  standards  systems  are  used  for  the  exchange  of 
electronic  information: 

♦  Standards  promulgated  by  the  American  National  Standards  Institute  Ac¬ 
credited  Standards  Committee  (ASC)  X12,  used  primarily  in  the  United 
States 

♦  United  Nations  Electronic  Data  Interchange  for  Administration,  Commerce, 
and  Transport  (UN/EDIFACT)  standards,  used  mostly  outside  the  United 
States,  predominantly  in  Europe. 

In  the  early  stages  of  its  electronic  commerce  program,  DoD  adopted  the  use 
of  ASC  X12  EDI  standards  for  exchanging  routine  business  information  with  its 
private-sector  trading  partners.  DoD  also  uses  ASC  X12  EDI  standards  for  many 
of  its  internal  systems  such  as  the  Defense  Logistics  Management  System.  A  cur¬ 
rent  worldwide  trend  to  use  UN/EDIFACT  EDI  standards  suggests  that  a  practi¬ 
cal  DoD  policy  over  the  long  term  would  be  to  support  UN/EDIFACT  as  the 
single  worldwide  EDI  standard. 

In  recognition  of  the  worldwide  trend  toward  the  use  of  UN/EDIFACT 
standards  and  the  current  DoD  use  of  ASC  X12  standards,  this  report  describes 
the  state  of  DoD  readiness  to  adopt  UN/EDIFACT  EDI  standards. 

The  report  examined  readiness  in  four  major  areas;  trading  partners,  sys¬ 
tems,  infrastructure,  and  workload.  While  DoD  has  made  substantial  progress  in 
the  use  of  EDI,  most  of  its  efforts  to  date  have  been  based  on  the  use  of  ASC  X12 


^Presidential  Executive  Memorandum,  subject.  Streamlining  Procurement  Through 
Electronic  Commerce,  October  26, 1993. 
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standards.  Thus,  additional  work  remains  before  DoD  will  be  ready  to  use 
UN/EDIFACT. 

Notwithstanding  the  current  use  of  ASC  X12  EDI  standards,  we  recommend 
that  DoD  adopt  and  vigorously  support  a  single  EDI  standard  for  exchanging 
business  information,  and  that  single  EDI  standard  should  be  UN/EDIFACT. 
Adoption  of  that  policy  now  will  enable  DoD  to  develop  the  trading  partner 
agreements,  systems,  and  infrastructure  it  needs  to  migrate  to  UN/EDIFACT. 

The  timing  of  the  DoD  migration  is  crucial.  If  DoD  migrates  too  soon,  it 
may  find  itself  without  a  substantial  number  of  trading  partners.  A  lack  of  trad¬ 
ing  partners  would  adversely  impact  readiness.  Also,  DoD  has  not  yet  deter¬ 
mined  whether  its  business  functioiis  can  be  accommodated  easily  by  existing 
UN  /EDIT  ACT  standards.  Our  experience  with  ASC  X12  EDI  standards  indicates 
the  likelihood  that  considerable  work  remains  before  DoD  can  adopt  and  use 
UN/EDIFACT  standards. 

We  recommend  that  DoD  not  migrate  unilaterally  to  an  exclusive  use  of 
UN/EDIFACT  standards.  Such  a  move  would  cut  DoD  off  from  the  majority  of 
its  current  and  potential  trading  partners,  and  those  partners  are  needed  if  DoD 
is  to  maintain  readiness  and  realize  the  economies  and  efficiencies  it  anticipates 
as  it  changes  from  a  paper-based  system  to  EDI.  DoD  should,  however,  take  an 
active  leadership  role  in  the  migration  process.  We  also  recommend  that  DoD 
take  the  following,  more  orderly,  phased  approach  to  its  eventual  migration  to 
UN/EDIFACT: 

♦  Allow  meirket  forces  to  determine  the  migration  to  UN/EDIFACT  standards 

♦  In  the  near  term,  continue  to  use  ASC  X12  standards  to  exchange  business 
information  with  trading  partners 

♦  Add  the  ability  to  support  UN/EDIFACT  standards  to  the  technical  infra¬ 
structure 

♦  Participate  in  the  UN /EDIFACT  standards-development  process  and  ensure 
the  standards  contain  required  DoD  business  functionality 

♦  Support  trading  partners  that  use  either  the  ASC  X12  or  UN/EDIFACT  stan¬ 
dards 

♦  Support  UN/EDIFACT-based  pilot  projects  to  build  early  experience,  dem¬ 
onstrate  commitment,  and  evaluate  impacts. 

In  summary,  we  foimd  DoD  to  be  progressing  well  toward  the  insertion  of 
EDI  technology  to  support  the  routine  exchange  of  business  information.  It  must 
now  define  its  EDI  strategy  for  the  future  and  align  that  strategy  with  emerging 
commercial  practices  and  Federal  policy  on  the  use  of  EDI  in  the  Federal  pro¬ 
curement  process.  If  it  does,  we  believe  DoD  will  be  well  positioned  for  an  even¬ 
tual  migration  to  UN/EDIFACT  in  a  manner  most  beneficial  to  itself  and  its 
worldwide  trading  partners. 
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Chapter  1 

Introduction 


In  this  chapter,  we  provide  a  brief  background  and  an  outline  of  the  organi¬ 
zation  of  the  report. 


Background 

The  Department  of  Defense  is  at  a  crossroad  in  the  evolution  of  its  electronic 
commerce  program.  It  makes  sense  for  DoD  to  adopt  a  long-range  policy 
of  "one  world  —  one  EDI  standard"  [with  that  standard  being  United  Nations 
Electronic  Data  Interchange  for  Administration,  Commerce,  and  Transport 
(UN /EDIFACT)],  but  it  must  decide  on  the  timing  of  its  migration  from  the  cur¬ 
rently  used  Accredited  Standards  Committee  (ASC)  X12  standard  to  the  use  of 
UN/EDIFACT  standards. 

In  its  current  electronic  data  interchange  (EDI)  applications,  DoD  uses  stan¬ 
dards  developed  by  ASC  X12  of  the  American  National  Standards  Institute 
(ANSI).  Those  standards  are  used  mostly  in  the  United  States  and  by  most  of 
DoD's  EDI-capable  trading  partners. 

In  the  past  several  yezirs,  the  EDI  community  has  seen  the  emergence  and 
rapid  expansion  of  international  standards  developed  under  the  auspices  of  the 
United  Nations  and  known  as  the  UN/EDIFACT  standards.  They  are  used 
worldwide,  predominantly  in  Europe. 

The  DoD  has  supported  a  single-standard  concept  and  now  wants  to  know 
the  state  of  its  readiness  to  migrate  from  the  currently  used  ASC  X12  EDI  stan¬ 
dards  to  the  use  of  UN/EDIFACT  standards.  To  help  DoD  answer  the  question 
"Is  DoD  ready  to  use  EDI  imder  UN/EDIFACT  standards?",  the  report  examines 
several  issues; 

♦  Readiness  of  DoD  to  perform  UN  /EDIFACT,  considering  the  following: 

►  Trading  partners 

►  Systems 

►  Support  infrastructures 

♦  The  workload  involved  if  DoD  migrates  to  the  use  of  UN/EDIFACT 

♦  The  differences  between  ANSI  ASC  X12  and  UN /EDIFACT  standards. 
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Report  Organization 

In  Chapter  2,  we  summarize  DoD's  readiness  to  migrate  to  UN/EDIFACT. 
We  also  assess  the  workload  involved. 

Chapter  3  provides  a  comparison  of  ASC  X12  and  UN/EDIFACT  standards, 
including  their  organizations,  their  procedures  for  preparing  standards,  and 
their  structures.  The  chapter  has  a  corollary  in  Appendix  A,  which  covers 
standards-makmg  organizations  and  procedures  in  greater  detail.  A  second  cor¬ 
ollary  to  this  chapter  is  Appendix  B,  which  covers  structural  and  other  major  dif¬ 
ferences  between  the  ASC  X12  and  UN/EDIFACT  standards. 

In  Chapter  4,  we  present  our  recommendations  and  provide  a  strategic  di¬ 
rection  for  DoD  in  its  migration  to  the  next  phase  of  its  EC  program. 

Appendix  C  is  a  listing  of  UN/EDIFACT  messages  by  status  category  and 
ASC  X12  transaction  sets.  Appendbc  D  is  a  compilation  of  EDI-related  terms  and 
a  glossary. 
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Chapter  2 


DoD  Readiness  to  Migrate 
to  UN/EDIFACT 


This  chapter  examines  DoD's  readiness  to  migrate  to  UN /EDIFACT.  It  also 
presents  an  assessment  of  the  estimated  workload  involved  in  a  migration  to 
UN/EDIFACT. 

Why  Consider  UN /  EDIFACT  Standards? 

In  1991  a  study  by  The  RAND  Corporation  recommended  that  DoD 
"...  should  do  nothing  to  preclude  the  use  of  EDIFACT  messages  by  DoD  ven¬ 
dors  and  should  support  the  development  and  improvement  of  those  stan¬ 
dards."^  We  believe  the  RAND  study  articxilated  the  correct  course  of  action  for 
DoD  to  follow. 

Many  EDI  users  we  spoke  with,  particularly  those  who  do  business  both  in 
the  United  States  and  abroad,  agreed  tiiat  a  single  EDI  standard  would  be  pre¬ 
ferred.  Other  EDI  users  supported  the  idea  of  a  single  EDI  standard  because 
they  would  only  have  to  acquire  and  maintain  one  type  of  translation  software. 

Our  research  revecded  an  ever-increasing  trend  toward  the  use  of 
UN/EDIFACT  standards  primarily  outside  the  United  States,  although  we  also 
saw  increased  UN/EDIFACT  activity  in  this  country  as  weU.  That  trend  sug¬ 
gests  UN/EDIFACT  will  likely  become  the  single  worldwide  EDI  standard. 

In  March  1992,  the  Cheiirman  of  ASC  X12,  was  asked  by  the  ANSI  Informa¬ 
tion  Systems  Standards  Board  (ISSB)  to  provide  information  on  the  U.S.  role  in 
EDIFACT  development  and  maintenance.  The  ASC  X12  Steering  Committee  felt 
that  a  ballot  would  be  the  most  expedient  way  for  the  membership  to  answer  the 
ISSB.  It  asked  the  ASC  X12  membership  to  vote  on  the  following: 

I  approve  that  X12  adopt  a  single  EDI  Standard,  which  is  EDIFACT,  after  the  release  of 

Version  4  of  the  X12  American  Natioml  Standard  which  is  expected  in  1997. 

The  ballot  was  a  policy  ballot  intended  to  set  strategic  direction  on  whether 
or  not  to  pursue  a  single  EDI  standard.  Table  2-1  shows  the  results  of  that  ballot. 
A  disapproval  vote  would  have  signaled  that  the  ASC  X12  membership  wanted 
to  continue  dual  ASC  X12  and  EDIFACT  standards  development  and  mainte¬ 
nance. 


'The  RAND  Corporation  Report,  A  Change  of  Course  -  The  Importance  to  DoD  of  Inter¬ 
national  Standards  for  Electronic  Commerce,  Judith  E.  Payne,  1991. 
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Table  2-1. 

ASCX12  Ballot  Results  —  Adopting  EDIFACT  as  a 
Single  EDI  Standard 


Action 

Number 

Ballots  mailed 

626 

Ballots  returned 

279 

Percent  ballots  returned 

45% 

Votes  approving 

213 

Votes  disapproving 

66 

Percent  returned  ballots  approving 

76% 

Note:  Data  from  ASC  X12  S/92-775  memorandum  dated  November  16, 1992. 


As  approved,  the  current  ASC  X12  policy  is  to  adopt  a  single  EDI  stan¬ 
dard  —  EDIFACT  —  after  Release  3070  (ANSI  Version  4).  Following  that  release, 
all  new  development  in  ASC  X12  would  be  in  EDIFACT  syntax,  using  the  EDI¬ 
FACT  data  dictionary. 

Regardless  of  the  outcome  of  the  vote,  some  members  of  the  EDI  community 
believe  that  ASC  X12  standards  should  continue  to  be  developed,  or  at  least  must 
be  available  and  maintained  indefinitely  to  meet  business  needs.  DoD  must  rec¬ 
ognize  that  not  all  EDI-capable  businesses  see  a  need  to  migrate  to 
UN/EDIFACT  standards.  Those  businesses  are  content  to  use  ASC  X12  EDI 
standeirds  and  will  likely  continue  to  do  so,  as  long  as  they  eire  available  and 
maintainable.  Some  of  those  businesses  are  current  and  potential  DoD  EDI  trad¬ 
ing  partners. 

The  ASC  X12  members  who  voted  for  adopting  EDIFACT  must  keep  in 
mind  that  accession  to  a  policy  is  easy  compared  with  developing  the  plan  and 
establishing  milestones  for  its  implementation.  At  present,  ASC  X12  has  char¬ 
tered  a  Task  Group  (Alignment)  to  develop  the  guidelines,  strategy,  and  imple¬ 
mentation  plan  necessary  to  put  the  results  of  the  vote  into  action.  The  plemning 
effort  is  under  way,  and  the  current  sense  of  the  membership  will  be  known 
aroimd  Jtme  1994. 

A  most  difficult  course  lies  ahead.  Merely  planning  how  ASC  X12  will  func¬ 
tion  in  the  future  is  not  enough.  Really  at  st^e  are  the  business  interests  of  the 
ASC  X12  membership.  Some  members  will  probably  seek  an  accommodation  to 
allow  ASC  X12  users  who  see  no  immediate  reason  to  use  EDIFACT  standards  to 
continue  using  ASC  X12  standards  (and  perhaps  to  continue  their  development 
as  well)  either  for  some  period  of  time,  or  indefinitely.  That  probability  is  very 
important  for  DoD  because  some  of  those  users  are  current  and  potential  DoD 
EDI  trading  partners. 

The  primary  reason  to  migrate  to  EDIFACT  is  to  meet  business  needs.  For 
that  reason,  while  it  is  vitally  important  how  ASC  X12  and  DoD  move  ahead,  it  is 
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equally  important  that  they  move  forward  from  a  base  of  commitment.  ASC  X12 
has  to  convince  parties  representing  an  installed  base  that  their  business  interests 
will  be  served.  If  ASC  X12  cannot  make  those  assurances,  the  U.S.  standards- 
setting  process  will  face  substantial  turmoil  over  the  next  several  years. 

Insofar  as  DoD  is  concerned,  we  believe  that  its  business  interest  will  be 
served  over  the  long  term  if  the  world  adopts  one  EDI  standard.  However,  DoD 
will  have  to  expend  time  and  effort  before  it  and  its  trading  partners  can  realize 
the  benefits  of  a  single  standard. 

For  its  part,  DoD  wiU  have  to  be  aware  of  the  market  forces  that  affect  deci¬ 
sions  to  migrate  to  UN/EDIFACT  and  plan  its  migration  in  harmony  with  those 
forces.  DoD  must  participate  in  the  ASC  X12  alignment  planning  effort  to  ensure 
its  views  are  made  known  and  to  maintain  currency  with  contemporary  ASC  X12 
planning  and  migration  efforts.  We  believe  that  by  participating  actively  in  the 
alignment  effort,  DoD  will  gain  invaluable  insights  into,  and  help  formulate,  a 
UN/EDIFACT  migration  strategy. 

Current  ASC  X12  draft  plans  for  alignment  with  UN/EDIFACT  call  for  no 
new  development  in  ASC  X12  syntax  after  Release  3070  (ANSI  Version  4).  This 
means  that  aU  DoD  ASC  X12  EDI  requirements  should  be  identified  and  started 
through  the  ASC  X12  standards  development  process  no  later  than  Jime  1995  to 
ensure  their  inclusion  in  Release  3070.  At  the  same  time,  DoD  must  ensure  that 
UN /EDIFACT  syntax  contains  needed  business  functionality  so  that  a  "bridge" 
exists  and  DoD  can  trade  freely  in  both  syntaxes. 


Readiness  to  Migrate  to  UN /  EDIFACT 

In  this  report,  we  look  at  trading  partners,  systems,  support  infrastructure, 
and  workload.  Following  our  examination  of  those  four  arecis,  we  emalyze  the 
data  gathered  and  draw  conclusions  about  where  DoD  is  on  a  continuum  de¬ 
scribed  as  "ready  to  migrate"  to  UN/EDIFACT.  At  the  end  of  this  chapter  we 
present  our  conclusions  on  that  readiness  in  tabular  form. 


Trading  Partners 

ASC  X12-CAPABLE  Trading  Partners 

About  30,000  business  entities  in  the  United  States  are  reputed  to  be  capable 
of  trading  using  one  or  more  ASC  X12  transaction  sets.  We  could  find  little  data 
on  the  number  of  businesses  using  EDI  let  alone  how  meiny  of  those  users  might 
be  current  or  potential  DoD  suppliers  and/or  trading  partners. 

In  our  dealing  with  the  ASC  X12  community,  we  know  of  some  DoD  suppli¬ 
ers  that  are  ASC  X12  EDI-capable.  We  believe  that  base  of  suppliers  is 
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sufficiently  large  to  support  near-term  goals  of  getting  started  and  gaining  expe¬ 
rience. 

To  date,  DoD  has  done  all  its  EDI  work  using  ASC  X12  standards.  New 
transaction  sets  have  been  developed  for  DoD  business  applications,  and 
changes  have  been  made  to  existing  ASC  X12  standards.  Therefore,  as  DoD  mi¬ 
grates  to  EDI,  it  will  be  able  to  draw  on  a  wide  range  of  ASC  X12  standards  al¬ 
ready  capable  of  carrying  DoD  data. 

To  illustrate,  the  Defense  Finance  and  Accounting  Service  —  Columbus  Cen¬ 
ter  pFAS-CO),  has  added  appropriate  business  functionality  to  ASC  X12  stan¬ 
dards  that  allows  vendors  to  use  the  ASC  X12  Invoice  (810)  transaction  set  to 
submit  commercial  invoices  electronically  to  DFAS-CO. 

In  another  example,  the  Defense  Logistics  Management  Systems  Office 
PLMSO)  developed  a  new  ASC  X12  transaction  set  (511)  that  can  be  used  to 
submit  requisitions  electronically  in  EDI  format.  That  new  transaction  set  was 
designed  for  use  within  DoD  and  can  also  be  used  by  DoD  contractors  author¬ 
ized  to  requisition  items  from  the  DoD  supply  system.  Because  it  is  a  public 
standard,  the  DoD-developed  511  transaction  set  can  also  be  used  within  the  pri¬ 
vate  sector  to  the  extent  that  it  contains  business  functionality  adequate  for  that 
use. 


UN/EDIFACT-Capable  Trading  Pakiners 

As  stated  earlier,  UN/EDIFACT  is  an  EDI  standard  used  predominantly 
outside  the  United  States.  We  did  not  find  authoritative  data  on  the  numbers  of 
current  UN/EDIFACT  users,  but  we  believe  the  number  to  be  between  10,000 
and  20,000  worldwide.  The  population  using  UN/EDIFACT  standards  is  pres¬ 
ently  smaller  than  the  population  using  ASC  X12  standards,  but  the  niunber  of 
users  grows  daily.  Some  current  UN/EDIFACT  users  are  actual  and  potential 
DoD  suppliers. 

The  issue  of  which  standard  to  use  does  not  preclude  DoD's  trading  in  both. 
If  DoD  subscribes  to  the  notion  of  "one  world—  one  EDI  standard"  and  that 
standard  is  to  be  UN/EDIFACT,  the  goal  is  charted.  All  that  remains  is  the  ques¬ 
tion  of  timing,  and  how  long  should  DoD  support  both  standards  under  the  as¬ 
sumption  that  DoD  cannot  stop  trading  in  ASC  X12  S5mtax  and  abruptly  switch 
to  the  exclusive  use  of  UN/EDIFACT. 

The  DoD  —  and  for  that  matter,  the  Federal  government  —  spends  many 
millions  of  dollars  abroad.  Since  UN/EDIFACT  is  the  EDI  standard  of  choice  in 
virtually  all  other  places  that  DoD  might  trade  heavily,  it  makes  sense  to  pursue 
such  a  trading  capability  for  that  reason  alone.  When  standardization,  harmoni¬ 
zation,  and  interoperability  issues  are  factored  into  the  equation,  they  make  a 
compelling  argument  for  migration. 
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Figure  2-1  illustrates  our  contention  that  while  more  potential  DoD  EDI 
trading  partners  in  the  world  now  use  ASC  X12  EDI  standards  than 
UN/EDIFACT  standards,  the  numbers  using  each  standard  will  reverse  over 
time.  Data  and  time  are  not  implied  in  this  figure;  the  only  implication  is  the 
concept  of  the  shift  in  standards  use  over  time. 


Figure  2-1. 

Comparison  of  EDI  Standards  Used  by  Potential  DoD  Trading  Partners 


The  key  to  ensuring  that  DoD  will  some  day  be  ready  to  migrate  to 
UN/EDIFACT  rests  on  DoD's  ability  to  make  a  sustained  commitment  of  time 
and  other  resources  to  the  UN/EDEFACT  standards  development  process.  That 
commitment  is  essential  if  any  assurance  is  to  be  given  that  UN/EDIFACT  stan¬ 
dards  will  one  day  support  DoD  business  functions.  The  immediacy  of  the  com¬ 
mitment  arises  from  the  fact  that  those  parties  that  set  standards  aie  assured  that 
their  business  functions  are  considered  in  the  process.  Parties  that  come  late  to 
the  process  either  accede  to  the  existing  standards  or  are  faced  with  the  often  dif¬ 
ficult  and  time-consuming  challenge  of  trying  to  change  them. 


Likely  Migrators  to  EDI 

Likely  migrators  to  EDI  are  most  emphatic  in  their  concern  that  they  maike 
only  one  major  new  investment  in  EDI.  Many  potential  EDI  users  who  could  be¬ 
come  DoD  trading  partners  are  waiting  to  see  how  DoD,  other  Federal  govern¬ 
ment,  private-sector  business  associates,  and  ASC  X12  policy  evolve  before  they 
commit  to  EDI.  Once  the  policy  is  clear,  we  believe  that  the  population  of  likely 
migrators  will  quickly  make  their  investments  in  EDI. 

Smadl  businesses  should  not  be  required  to  support  first  one  and  then  an¬ 
other  EDI  standard.  We  believe  a  more  prudent  course  of  action  will  be  for  DoD 
to  commit  to  using  UN/EDIFACT  standards,  but  let  the  market-place  determine 
the  EDI  standard  of  choice  for  any  given  trading  partner.  In  that  scenario,  DoD 
must  be  prepared  to  support  both  standards  for  a  period  of  time.  That  course  is 
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not  particularly  challenging  either  in  terms  of  technology  or  the  resources  re¬ 
quired.  A  more  detailed  discussion  of  it  is  presented  later  in  this  chapter. 


What  EDI  Capabilities  Should  Trading  Partners  Have? 

Some  DoD  suppliers  have  developed  applications  for  their  private-sector 
businesses,  and  those  applications  can  be  adapted  to  trading  with  DoD.  Others 
have  applications  that  bear  little  resemblance  to  the  t5rpe  of  data  DoD  requires  to 
complete  an  effective  EDI  exchange. 

As  an  example,  if  DoD  is  capable  of  issuing  a  purchase  order,  a  DoD  trading 
partner  taking  full  advantage  of  EDI  should  have  an  order-entry  system.  If  the 
trading  partner  cannot  accept  a  DoD  EDI  order  without  reducing  it  to  paper, 
DoD  will  be  EDI-capable  but  the  trading  partner  will  not.  However,  that  situa¬ 
tion  does  not  necessarily  mean  that  DoD  cannot  trade  with  a  business  unless  it  is 
EDI-capable.  Successful  trading  from  DoD's  perspective  also  depends  on  three 
other  important  factors. 

First,  DoD  must  accept  the  premise  that  its  applications  and  translation  soft¬ 
ware  must  be  able  to  deliver  standard  EDI  data  to  a  telecommunications  system 
accessible  to  its  trading  partners. 

Second,  EDI-capable  trading  partners  will  need  at  least  an  electronic  address 
to  receive  DoD  business  data. 

Third,  if  DoD  trading  partners  choose  not  to  be  EDI-capable,  they  will  have 
to  acquire  the  capability  to  receive  DoD  data  in  some  other  manner.  Typically, 
value-added  networks  (VANs)  have  offered  such  services  to  businesses  that  do 
not  wish  to  use  EDI.  A  likely  scenario  in  that  situation  would  have  DoD  trans¬ 
mitting  a  business  transaction  in  EDI  format  and  routing  it  to  an  electronic  ad¬ 
dress  at  a  trading  partner's  VAN.  When  DoD  data  curive,  the  VAN  translates 
them  and  puts  them  into  a  format  chosen  by  the  customer. 

Such  a  scenario  should  be  adequate  for  DoD  since  it  cannot  control  the  busi¬ 
ness  decisions  of  its  potential  trading  partners. 

In  the  long  term,  DoD  should  not  use  EDI  with  some  suppliers  to  satisfy  in¬ 
ternal  requirements,  and  at  the  same  time  continue  to  support  the  same  business 
functions  in  a  paper-based  format.  To  use  both  mediums  would  be  inefficient 
because  maintaining  two  systems  will  consume  all  potential  savings  and  other 
benefits  and  prove  to  be  more  costly  in  the  long  run.  DoD  should  quickly  con¬ 
vert  appropriate  paper-based  systems  to  ffie  use  of  EDI  whenever  it  is  deter¬ 
mined  to  be  feasible  and  practical  to  do  so. 
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A  Possible  Solution 


The  DoD  should  consider  satisf5dng  both  its  ASC  X12-capable  and  its 
UN/EDIFACT-capable  trading  partners  at  the  same  time.  Such  a  course  of  ac¬ 
tion  is  possible  for  little  additional  investment  in  translation  and  table-driven 
software,  as  shown  in  Figure  2-2.  If  DoD  develops  such  a  capability,  it  could  use 
either  standard  depending  on  which  was  used  by  its  trading  partner.  It  would 
become  a  simple  matter  of  looking  up  the  trading  partner's  capabilities  in  a  data 
base  and  then  formatting  an  EDI  transmission  accordingly. 


Trading 

OoO  partnerA 


Note:  This  figure  is  represerrtattve  of  one  or  more  translators  using  ASC  X12  and  UN/EDIFACT  software 
and  having  a  capability  to  look  up  in  tables  the  needs  of  a  specific  trading  partner.  The  operation  is  bidirec¬ 
tional. 

Figure  2-2. 

Exchanging  EDI  with  Both  ASC  X12-  and  UN/EDIFACT-Capahle 
Trading  Partners 

Our  recent  work  in  the  area  of  international  logistics  harmonization  suggests 
that  while  European  companies  would  like  DoD  to  use  UN/EDIFACT  immedi¬ 
ately,  they  may  be  willing  to  take  a  more  gradual  approach  as  long  as  some 
UN/EDIFACT  work  is  begun  in  the  near  term.  We  support  such  a  course  of  ac¬ 
tion  and  recommend  that  DoD  and  its  allies  select  one  or  more  pilot  projects  on 
which  the  use  of  UN/EDIFACT  S5mtax  and  international  harmonization  issues 
can  be  tested. 


Summary 


Will  DoD  support  both  standards?  If  so,  for  how  long?  If  we  assume  that 
DoD  will  continue  to  trade  primarily  with  U.S.-based  trading  partners,  then  it  is 
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likely  those  data  exchanges  will  take  place  for  some  time  in  ASC  X12  EDI  stan¬ 
dards.  The  shift  from  ASC  X12  standards  will  occur  only  when  some  circum¬ 
stance  causes  trading  partners  to  migrate  to  UN/EDIFACT  standards.  We 
believe  that  the  number  of  UN/EDIFACT  users  in  the  world  will  ^ow  substan¬ 
tially  and  that  growth  will  be  dependent  upon  the  tests  of  feasibility  and  practi¬ 
cality,  influenced  by  four  primary  factors: 

♦  EDI  use  win  become  more  popular. 

♦  The  world  will  move  toward  a  global  economy. 

♦  Users  of  ASC  X12  standards  will  migrate  toward  UN/EDIFACT  standards. 

♦  DoD  will  support  international  standardization  and  harmonization  initia¬ 
tives  with  its  allies. 


Conclusion 

We  conclude  that  the  population  of  actual  and  potential  trading  partners 
with  whom  DoD  will  exchange  data  in  EDI  format  is  not  now  capable  of  sup¬ 
porting  DoD  requirements  using  either  ASC  X12  or  UN/EDIFACT  standards. 
For  that  reason  we  believe  that  a  dual  capability  will  Etfford  DoD  its  greatest  op¬ 
portunity  to  trade  using  EDI.  However,  as  DoD  and  its  trading  partners  move  to 
a  single  EDI  standard  over  time,  the  overlap  will  diminish  as  shown  in 
Figure  2-3. 


Standard 


Figure  2-3. 

Use  of  EDI  Standards  During  the  Migration  to  UN/EDIFACT 


We  believe  that  DoD  should  continue  its  present  course  of  supporting  EDI 
using  ASC  X12  standards.  At  the  same  time,  we  believe  that  DoD  should 
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continue  to  work  toward  adopting  a  policy  of  "one  world  —  one  EDI  standard" 
with  that  one  standard  being  UN/EDIFACT. 


Systems 

Background 


The  former  Office  of  the  Executive  Agent  (EA)  for  EDI  at  the  Defense  Logis¬ 
tics  Agency  (DLA)  defined  DoD  EDI  systems.  We  found  that  the  architecture 
described  by  the  EA  and  later  articulated  by  the  acquisition  reform  process  ac¬ 
tion  team  are  being  put  in  place.  The  rest  of  the  EDI  system  is  in  the  process  of 
being  further  defined,  acquired,  installed,  or  implemented. 

The  issue  of  which  standards  are  used  is  of  little  concern  in  terms  of  EDI  sys¬ 
tem  hardware  and  telecommunications.  A  system  that  is  properly  constructed 
and  sized  should  be  capable  of  handling  data  regardless  of  the  syntax  used.  The 
issue  impacting  architecture  is  one  of  supporting  a  single  standard  versus  a  dual 
standard.  We  encourage  DoD  to  ensure  that  its  EDI  system  architecture  can  sup¬ 
port  a  ducil  capability  imtil  the  migration  to  a  single  standard  is  complete. 


System  Components 

In  considering  systems  and  the  related  investment  associated  with  EDI,  we 
must  separately  consider  the  following  components: 

♦  Architecture 

♦  Hardware 

♦  Telecommunications  interconnectivity 

♦  Application  programs 

♦  Translation  software. 


Architecture 


The  DoD's  examination  of  various  system  architectures  resulted  in  the  defi¬ 
nition  of  initial  and  notional  target  system  architecture.  We  note  the  baseline,  as 
outlined  by  the  acquisition  reform  process  action  team,  and  believe  it  is  adequate 
to  support  the  EC  program  for  some  time  to  come  as  long  as 

♦  it  is  properly  sized  and 

♦  it  conforms  to  the  emerging  concept  of  the  virtual  network  being  articulated 
as  the  Federal  EDI  architecture  by  the  Federal  government 


2-9 


Although  DoD  has  already  made  an  investment  in  its  EDI  system  architec¬ 
ture,  some  additional  investment  will  be  required  before  it  will  have  an  end-to- 
end  system  capable  of  supporting  its  EDI  needs.  The  process  action  team  in  its 
report  used  a  figure  of  $26  million.  We  see  no  reason  to  challenge  that  figure. 

The  DoD  started  using  an  EDI  system  several  years  ago.  At  that  time,  it  fo¬ 
cused  on  the  use  of  ASC  X12  standards.  EDI  system  architecture  is,  for  the  most 
part,  standards-neutral;  that  is,  with  limited  exceptions,  a  properly  designed  sys¬ 
tem  should  be  capable  of  supporting  the  EDI  s)mtax  of  choice.  We  believe  that 
DoD  system  designers  understand  and  will  implement  this  concept. 

Caution  must  be  applied  to  those  places  in  the  target  architecture  that  could 
be  perceived  to  be  bottlenecks  to  the  flow  of  data  or  could  actually  be  such.  Any 
time  information  has  to  flow  through  one  point,  that  point  has  a  potential  to  im¬ 
pede  the  flow  of  data.  DoD  business  operations  are  often  time-sensitive,  with  the 
procurement  process  being  a  prime  example.  Wartime  and  readiness  issues  add 
yet  another  dimeiision  of  time  criticality.  Thus,  every  effort  must  be  made  to 
ameliorate  the  potential  for  data  flow  disruption.  That  can  be  accomplished  in 
several  ways: 

♦  Ensure  that  from  the  outset,  internal  and  external  telecommxmications  sys¬ 
tems  are  adequately  sized  for  current  and  anticipated  traffic  volume 

♦  Ensure  redimdancy  and  alternative  routing  capabilities 

♦  Develop  a  system  operating  procedure  and  execute  it  through  a  centrally 
managed  organizational  structure. 

The  system  architecture  must  be  made  available  on  a  time-phased,  critical- 
path,  milestone  schedule  consistent  with  other  EC  goals.  Furthermore,  DoD 
must  ensure  that  from  the  outset  its  EC  system  architecture  is  properly  sized  and 
adequately  budgeted  and  that  time-phased  system  procurements  are  imdertaken 
so  that  components  aie  in  place  when  needed.  That  need  should  be  defined  as  a 
oirve,  and  the  curve  should  be  in  harmony  with  Service  and  agency  plans  for 
migration  to  EDI. 


Hardware 


The  DoD  has  a  computer-literate  work  force  and  a  robust  inventory  of  per¬ 
sonal  computers  already  on  hand.  For  that  reason,  we  believe  that  it  has  ac¬ 
quired  much  of  the  low-end  hardware  needed  to  develop  its  EC  system. 

Some  hardware  investment  will  be  required  on  the  high  end  to  support  the 
system  architecture  and  eventu2d  rational  data  bases,  but  we  believe  that  such 
investment  can  be  accommodated  with  careful  planning,  even  in  times  of  austere 
budget  constraints.  The  investment  must  be  made  regeirdless  of  the  EDI  stan¬ 
dard  or  standards  adopted. 
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Telecommunications  Interconnectivity 


Telecommunications  interconnectivity  is  one  of  the  key  ingredients  in  an 
EDI  system.  As  the  number  of  DoD  trading  partners  grows,  demands  placed  on 
internal  and  external  telecommimications  systems  will  increase. 

The  issue  of  telecommunications  interconnectivity  has  been  addressed  by 
DoD.  Current  DoD  planning  suggests  the  use  of  existing  networks  with  the  ad¬ 
dition  of  one  or  more  access  points  to  be  used  as  points  of  connectivity  between 
the  internal  and  external  systems.  The  Defense  Automatic  Addressing  System 
Office  (DAASO)  or  an  office  providing  similar  functionality  will  likely  play  a  key 
role  in  establishing  telecommunications  interconnectivity. 

The  DoD  will  rely  heavily  on  one  or  more  hubs  (or  network  entry  points) 
and  VANs  to  achieve  needed  external  telecommunications  interconnectivity. 
While  some  trading  partners  should  be  allowed  to  connect  directly  to  distribu¬ 
tion  points  where  it  is  feasible  and  practical  to  do  so,  the  bulk  of  the  telecommu¬ 
nications  interconnectivity  will  be  through  mutually  supporting  VANs.  This 
concept  is  in  keeping  with  the  private-sector  way  of  interconnecting  EDI  trading 
peulners. 

Value-added  networks  provide  the  private  sector  with  EDI  telecommunica¬ 
tions  interconnectivity,  mailboxes,  message  translation  services,  and  other  func¬ 
tions  associated  with  other  than  point-to-point  EDI  systems.  DoD  heis  experience 
in  dealing  with  and  using  commercial  VAN  services  from  its  ongoing  EDI  pro¬ 
jects. 

Currently,  DoD  is  working  on  a  universal  VAN  agreement  that  would  likely 
expand  its  current  ability  to  communicate  with  its  EDI  trading  partners.  DoD 
should  test  and  certify  all  VANs  it  intends  to  use  as  a  part  of  its  EDI  architecture 
and  telecommunications  interconnectivity  plan. 


Application  Programs 

Information  system  architects  generally  know  that  EDI  is  an  application- 
program-to-application-program  system  regzirdless  of  which  standard  is  used. 

Thus,  the  critical  path  for  any  EDI  migration  strategy  must  include  the  de¬ 
velopment  of  application  programs.  If  EDI  is  selected  as  a  technology  to  move 
data,  it  should  be  selected  because  it  facilitates  the  use  of  data  by  disparate  but 
complementary  application  programs.  For  exsimple,  a  willing  trading  partner 
(i.e.,  one  who  intends  to  take  advantage  of  trading  with  DoD)  might  want  to 
have  an  EDI  order-entry  system  to  complement  (and  receive)  orders  from  a  DoD 
EDI  order-placement  system. 

When  we  asked  whether  DoD  has  application  programs  for  its  EC  system, 
we  found  that  in  some  cases  application  programs  exist  and  in  other  cases,  they 
are  either  under  development  or  their  development  is  contemplated. 
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Development  of  application  programs  will  take  a  great  deal  of  the  time  and  re¬ 
sources  available  for  EDI  migration. 

Application  program  development  will  draw  on  EDI  resources,  and  those 
costs  must  be  considered  in  any  budgetary  planning.  We  also  believe  that  appli¬ 
cation  programming  is  a  key  milestone  on  the  critical  path. 

The  DoD  must  ensure  that  in  spending  EDI  resources,  it  gives  highest  prior¬ 
ity  to  conversion  or  development  of  only  those  systems  that  contribute  to  the 
overall  DoD  EC  strategy.  To  ensure  those  priorities,  DoD  must  ensure  that  appli¬ 
cation  programs  are  developed  only  to  support  a  well-defined  EC  strategy.  It 
can  do  so  by  fund  control,  detailed  implementation  milestone  planning  and 
scheduling,  and  periodic  progress  review. 

For  example,  if  DoD  develops  the  ability  to  send  out  electronic  requests  for 
quotations  (RFQs)  in  EDI  format,  it  will  have  a  suboptimal  system  unless  it  can 
^so  receive  and  process  EDI-formatted  responses  to  those  RFQs  electronically. 
When  an  award  is  to  be  made,  DoD  must  also  be  able  to  format  an  EDI  purchase 
order  and  transmit  it  to  a  trading  partner  who  hopefully  wiU  have  an  order-entry 
system.  In  turn,  that  order-entry  system  will  use  data  already  on  hand  to  gener¬ 
ate  shipment  notices  and  invoices  to  DoD,  and  so  on. 

To  the  extent  that  DoD  EDI  trading  partners  have  corollary  application  pro¬ 
grams,  they  will  be  able  to  optimize  the  value  of  migrating  to  EDI.  If  they  do  not 
have  corollary  EDI  application  programs,  they  will  have  to  acquire  them  or  con¬ 
tract  for  a  third  party  (i.e.,  a  VAN)  to  provide  the  service.  Failure  to  have  those 
coroUetry  applications  will  slow  down  the  accession  of  EDI  trading  partners. 

While  the  aveiilability  of  trading  partner  application  programs  must  be  con¬ 
sidered,  DoD  should  be  resolute  in  its  efforts  to  migrate  to  a  system  of  EC.  Un¬ 
der  no  circumstances  should  DoD  be  willing  to  compromise  on  its  EC  goeil  by 
providing  both  an  EDI  and  a  paper-based  capability.  It  is  essential  to  move  to¬ 
ward  full  EC,  and  that  goed  can  only  be  through  the  full  migration  of  applicable 
business  exchanges. 

In  suirunary,  while  we  saw  some  work  being  done  to  create  application  pro¬ 
grams  for  use  in  the  DoD  EC  system,  much  additional  work  remains. 


Translation  Software 

Translation  software  for  UN/EDIFACT  is  readily  available  in  tiie  commer¬ 
cial  market.  It  is  updated  regularly  (typically  in  time  to  coincide  with  the  publi¬ 
cation  of  an  updated  version/release  of  UN/EDIFACT  standards).  Whether  the 
translatable  UN/EDIFACT  messages  can  support  DoD  business  functionality  is  a 
different  issue. 

From  an  examination  of  a  recent  compilation  of  EDI  software  vendors  and 
products,  we  conclude  that  most  U.S.  translation  softwcu-e  vendors  have  focused 
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on  products  to  support  ASC  X12  transaction  sets  since  that  EDI  S5Titax  is  in  com¬ 
mon  use  in  the  United  States  (notwithstanding  current  trends  by  large  multina¬ 
tional  businesses  to  also  use  UN/EDIFACT).  Many  of  those  vendors  also  market 
products  that  support  UN/EDIFACT.  While  the  UN/EDIFACT  translation  soft¬ 
ware  market  in  Ae  United  States  is  not  yet  as  robust  as  the  ASC  X12  translation 
software  market,  we  predict  it  will  become  more  robust  as  businesses  shift  to 
UN/EDIFACT.  Foreign  sources  of  UN/EDIFACT  translation  software  exist  in 
adequate  numbers. 

Some  cost  wiU  be  associated  with  the  acquisition  of  UN/EDIFACT  transla¬ 
tion  software.  However,  that  cost  wiU  be  minimal  in  comparison  to  the  cost  of 
making  the  other  parts  of  the  DoD  EDI  system  operational. 


Support  Infrastructure 

We  believe  that  some  difficult  issues  in  the  support  infrastructure  area  re¬ 
main  to  be  resolved  as  DoD  evaluates  its  readiness  to  use  UN/EDIFACT. 

The  international  aspects  of  defense,  the  need  for  standardization  and  har¬ 
mony,  and  the  increasing  recility  of  a  global  economy  signal  the  need  to  achieve  a 
more  common  basis  for  data  interchange.  UN/EDIFACT  holds  the  greatest  po¬ 
tential  for  achieving  that  end  with  respect  to  the  exchanges  of  routine  business 
information.  However,  in  using  UN/EDIFACT,  DoD  wiU  have  to  deal  with 
many  support  infrastructure  issues  and  also  look  for  improvements  in  the  whole 
process  of  UN/EDIFACT  standards  development 


UN/EDIFACr 

Business  Functionality 

The  DoD  must  ensure  that  its  business  functions  can  be  supported  by 
UN/EDIFACT  standards.  Table  B-16  and  Appendix  C  elaborate  in  a  macro  way, 
on  how  much  of  DoD's  broad  business  functionality  can  be  presently  supported 
by  UN/EDIFACT  syntax  messages.  However,  imtil  a  detailed  study  is  per¬ 
formed  to  determine  what  data  can  be  carried  in  those  messages,  DoD  will  not 
know  how  well  current  and  developmented  UN/EDIFACT  standeuds  can  sup¬ 
port  its  business  requirements  and  how  many  changes  to  those  stcmdards  will 
have  to  be  made. 


Efficiency 


Over  the  past  year,  we  have  seen  some  improvement  in  the  standards- 
making  process.  We  believe  that  as  more  people  become  involved  and  the  proc¬ 
ess  matures,  it  wiU  become  more  efficient.  Nevertheless,  moving  requirements 
through  the  UN/EDIFACT  standards  approval  process,  as  with  any  similar 
process,  can  be  time-consuming. 
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The  DoD  can  improve  efficiency  in  the  standards-making  process  by  partici¬ 
pation.  If  DoD  commits  the  resources  needed  to  participate  in  the  standards- 
making  process,  it  will  ensure  that  it  has  optimized  its  potential  for  moving  its 
requirements  through  a  process  that  is,  and  will  remain  somewhat  cumbersome. 


Availability  ofUN/EDIFACT  Messages 

The  availability  of  standards  may  be  compared  in  two  ways: 

♦  Numbers  of  standards  at  different  stages  of  development 

♦  Business  functionality  of  existing  standards. 

Merely  comparing  numbers  of  developed  standards  is  not  sufficient  by  itself 
as  a  credible  discriminating  factor  in  selecting  which  standard  to  use.  More 
ASC  X12  transaction  sets  have  been  developed  partially  because  ASC  X12  began 
developing  transaction  sets  sooner  and  also  because  it  included  many  industry- 
specific  transaction  sets  in  standards.  A  more  accurate  measure  of  standard  us¬ 
ability  can  be  obtained  only  when  a  detailed  comparison  of  the  included  busi¬ 
ness  functionality  of  each  standard  is  made.  Several  factors  lead  us  to  believe 
that  ASC  X12  currently  has  greater  utility  to  DoD. 

♦  ASC  X12  standards  encompass  a  wider  range  of  transactions  useful  to  DoD. 

♦  DoD  is  participating  in  the  ASC  X12  standards  development  process,  thus 
ensuring  DoD  business  functionality  is  included  in  selected  ASC  X12  trans¬ 
action  sets. 

Notwithstanding,  we  expect  that  over  the  next  several  years  UN/EDIFACT 
message  capabilities  will  equal  those  of  ASC  X12.  Dedicated  support  to  the 
UN/EDIFACT  standards  development  process  will  enable  it  to  catch  up  to 
ASC  X12  even  sooner. 


Binary,  or  Transparent,  Data 

Fimdamental  to  the  ASC  X12  standard  design  is  the  precept  that  business  in¬ 
formation  is  to  be  transmitted  within  the  body  of  a  transaction  set  and  data 
transmitted  must  be  independent  of  the  means  of  telecommunication.  Great  care 
has  been  exercised  over  time  to  ensure  that  all  new  development  adhered  to  that 
precept.  ASC  X12  and  UN/EDIFACT  differ  on  the  placement  of  transpeirent  data 
in  the  respective  standards. 

We  do  not  intend  to  revisit  the  differing  solutions  suggested  for  moving 
transparent  data  in  an  EDI  context.  Although  both  ASC  X12  and  UN/EDIFACT 
offer  solutions,  the  solutions  are  not  entirely  interchangeable. 
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We  are  aware  of  recent  proposals  to  treat  transparent  data  in  UN/EDEFACT, 
including  carrying  it  in  the  enveloping  structure  of  a  message.  That  proposal  ap¬ 
pears  to  be  gaining  in  popularity.  We  commend  it  and  other  initiatives  to  re¬ 
solve  this  issue.  Since  DoD  will  need  to  transmit  large  amotmts  of  transparent 
data  primarily  associated  with  its  acquisition  process,  it  has  a  stake  in  how  the  is¬ 
sue  gets  resolved  and  thus  should  become  involved  in  the  issue  resolution  proc¬ 
ess. 


REGBTEtATION  OF  TRADING  PARTNERS 

Proper  use  of  EDI  systems  involves  more  than  merely  the  decision  to  trade; 
trading  partners  must  know  a  lot  about  each  other  to  facilitate  effective  trading. 
To  achieve  that  end,  DoD  should  teike  the  following  actions  to  ensure  the  suc¬ 
cessful  registration  of  trading  partners: 

♦  Develop  a  set  of  EDI  system  operating  procedures  and  make  them  available 
electronically  to  potential  trading  partners. 

♦  Centrally  manage  the  registration  process  so  that  a  vendor  need  only  regis¬ 
ter  once,  regardless  of  who  the  DoD  trading  partner  will  be.  This  central 
registration  should  eventually  migrate  to  a  Federal  registry. 

♦  Determine  what  information  is  needed  to  establish  a  trading  partner  rela¬ 
tionship. 

♦  Require  potential  trading  partners  to  register  and  periodically  update  their 
files  electronically. 

♦  Use  the  ASC  X12  Transaction  Set  838,  Trading  Partner  Profile,  or  a 
UN/EDIFACT-equivalent  message  when  available. 

♦  Develop  a  registration  data  base  that  will  distribute  data  to  other  systems. 


Trading  Partner  Agreements 

Trading  partner  agreements  (TP As)  are  used  to  specify  the  terms  and  condi¬ 
tions  applicable  to  EDI  trading  between  parties.  DoD  has  used  TP  As  in  the  past 
and  is  continuing  its  development  of  a  single  TPA  that  can  be  used  by  all  DoD 
activities. 


Establishment  of  Trading  Partner  Agreements 

A  general  practice  of  the  EDI  user  community  is  to  establish  agreements  be¬ 
tween  trading  partners.  Those  agreements  are  necessary  to  ensure  that  both  par¬ 
ties  to  the  trade  are  made  aware  of  the  following  essential  information: 
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♦  Rights  and  responsibilities 

♦  Technical  and  administrative  information  necessary  to  effect  a  trade. 

We  recommend  DoD  use  a  centrally  managed  registration  system  encom¬ 
passing  the  electronic  registration  of  trading  partners.  Such  a  system  could  be 
used  for  a  variety  of  pxuposes: 

♦  It  could  eliminate  paper-based  registration  with  its  attendant  storage  and 
maintenance  requirements. 

♦  It  could  require  trading  partners  to  maintain  currency  of  data. 

♦  It  could  eliminate  the  need  for  decentralized  systems  and  repetitive  registra¬ 
tions. 

We  believe  that  the  ASC  X12  Transaction  Set  838,  and  eventually  an  equiva¬ 
lent  message  in  UN/EDEFACT,  should  be  used  for  electronic  trading  partner  reg¬ 
istration.  DoD  worked  out  the  concept  of  electronic  registration  of  trading 
partners  as  part  of  the  Air  Force's  government  acquisition  through  electronic 
commerce  (GATEQ  project  at  Wright-Patterson  Air  Force  Base.  Implementation 
conventions  (ICs)  for  registration  and  confirmation  of  registration  were  pro¬ 
duced  and  delivered  to  the  GATEC  project  as  draft  DoD  ICs.  Those  ICs  and  a 
more  robust  one  done  for  the  Federd  government  are  available  for  review  and 
eventual  use.  DoD  will  eventually  have  to  migrate  its  registration  business  func¬ 
tionality  to  UN/EDIFACT  if  it  intends  to  have  electronic  registration  of  its 
UN/EDIFACT-capable  potential  trading  partners. 


Configuration  Control  of  the  EDI  Environment 

Many  aspects  of  configtuation  control  have  to  be  worked  out  before  trading 
can  take  place  in  an  optim^  environment.  Among  them  are  the  following: 

♦  determination  of  the  standard  used, 

♦  selection  of  the  business  functionality, 

♦  version/  release  of  the  standard,  and 

♦  implementation  conventions  linked  to  the  selected  version/ release  of  the 
standard. 


Which  Standard  to  Use 

In  the  near  term,  DoD  should  exchange  with  trading  partners  using  ASC  X12 
standards  and  should  immediately  begin  to  acquire  the  capability  to  use 
UN/EDIFACT  standards.  Once  it  has  acquired  that  capability,  DoD  should 
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afford  trading  partners  the  option  of  trading  using  one  or  the  other  standard. 
Eventually,  driven  by  market  forces,  DoD  should  migrate  to  an  EDI  system  using 
only  UN/EDIFACT  standards. 


Version/Release  of  Standards 

Both  ASC  X12  and  UN/EDIFACT  standards-making  bodies  periodically 
issue  versions/ releases  of  their  standards.  Those  versions/ releases  pose  a  poten¬ 
tial  problem  when  trading  partners  who  are  using  the  same  type  of  standard  are 
using  different  versions/releases.  The  problem  occurs  only  when  changes  have 
been  made  from  one  version/release  to  the  next.  In  that  case,  trading  partners 
may  not  be  able  to  trade  without  making  changes  to  translators,  applications,  or 
both. 

Another  problem  arises  when  one  trading  partner  wishes  to  exchange  a  dif¬ 
ferent  set  of  transactions  (or  messages)  than  does  the  other  partner.  For  example, 
take  the  case  in  which  one  trading  partner  wishes  only  to  receive  orders  even 
though  the  DoD  EC  process  is  based  on  solicitation  (RFQ),  quote,  and  order 
transaction  sets.  That  trading  partner  has  no  capability  to  receive  or  respond  to 
RFQs  and  must  acquire  it. 


Configuration  Control  of  Implementation  Conventions 

An  IC  is  a  recording  of  the  manner  in  which  trading  partners  agree  to  use  a 
specific  transaction  set  Since  any  two  trading  partners  are  unlikely  to  use  the 
f^  potential  of  a  transaction  set  they  typically  agree  on  how  a  transaction  set 
will  be  used.  That  agreement  is  often  formally  recorded  in  an  IC. 

Because  DoD  Services  and  agencies  launched  a  wide  range  of  internal  EDI 
initiatives,  DoD  presently  lacks  configuration  control  over  ICs  being  used  by  the 
Services  and  DLA.  This  critical  issue  must  be  resolved  as  soon  as  possible. 

Some  trading  partners  will  already  be  using  EDI  when  DoD  signals  that  it, 
too,  is  ready  to  begin  trading.  In  those  cases  it  is  likely  that  some  trading  part¬ 
ners  will  want  DoD  to  trade  in  accordeince  with  the  way  they  are  already  con¬ 
ducting  similar  trades  because  many  of  those  traders  are  part  of  large  industry 
groups  that  have  already  hammered  out  the  agreements  among  themselves  on 
how  certain  transaction  sets  will  be  traded. 

Those  potential  trading  partners  will  be  willing  to  trade  with  DoD;  but,  if 
DoD  deviates  substantially  from  the  way  they  are  now  trading,  they  will  have  to 
expend  resources  to  deal  with  the  problem.  We  can  reasonably  presume  that 
many  of  those  potential  traders  will  balk  at  the  idea  and  bring  pressure  to  bear 
on  DoD  to  accommodate  their  way  of  trading. 

Control  of  ICs  leads  to  the  question  of  whether  DoD  should  be  willing  to  ac¬ 
commodate  aU  or  some  of  its  trading  partners  or  whether  it  should  develop  a 
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single  convention  and  trade  only  with  partners  willing  to  adapt  to  that  conven¬ 
tion.  Those  questions  need  further  study. 

Figure  2-4  illustrates  the  problem  DoD  could  face  when  trying  to  trade  with 
a  disparate  population  of  vendors  who  use  different  types  and  versions/ releases 
of  standards,  who  have  different  trading  capabilities,  and  who  use  different  im¬ 
plementation  conventions.  The  resolution  of  that  problem  is  difficult,  but  the 
problem  must  be  faced  if  DoD  intends  to  appeal  to  a  wide  group  of  potential 
trading  partners. 


Figurie  2-4. 

Using  EDI  with  a  Disparate  Population  of  Trading  Partners 

Current  EDI  standards  are  used  by  different  groups  of  trading  partners  in 
different  ways.  For  example,  while  some  of  the  data  are  the  same  in  both  t5q)es 
of  orders,  the  data  needed  in  an  order  for  spare  parts  likely  differs  from  the  data 
needed  in  an  order  for  clothing.  Notwithstanding  the  data  disparity,  both  order¬ 
ing  parties  can  use  the  same  standard  (i.e.,  the  ASC  X12  Transaction  Set  850,  Pur¬ 
chase  Order,  or  the  UN/EDIFACT  ORDERS  message).  The  differences  can  be 
documented  in  an  IC  and  software  employed  to  process  both  order  types. 

While  DoD  has  some  draft  ICs  for  ASC  X12  transaction  sets,  none  yet  exist  in 
DoD  for  UN/EDIFACT  messages.  DoD  must  ensure  that  messages  exist  in 
UN/EDIFACT  S5mtax,  it  must  determine  the  extent  to  which  its  business  func¬ 
tionality  can  be  transmitted  in  UN/EDIFACT,  and  then  it  must  develop,  coordi¬ 
nate,  publish,  and  maintain  configuration  control  over  UN/EDIFACT-based  ICs. 
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It  is  imperative  for  DoD  to  participate  in  efforts  to  develop  government- 
wide  implementation  conventions  for  use  by  all  departments  and  agencies  of  the 
government.  Further,  any  DoD  IC  efforts  on  standards  or  ICs  should  be  coordi¬ 
nated  and  consistent  with  government-wide  efforts. 


The  Issue  of  Version/Release  Control 

K  vendors  are  allowed  to  trade  with  DoD  in  either  ASC  X12  or 
UN/EDIFACT  syntax,  it  will  multiply  the  problems  associated  with  maintaining 
version  and  release  control  of  standards  between  trading  partners.  Resolution  of 
the  problem  can  only  be  achieved  when  DoD  addresses  these  issues: 

♦  Differences  in  data  dictionaries 

♦  Multiple  versions  and  releases  of  both  ASC  X12  and  UN/EDIFACr  stan¬ 
dards 

♦  Installed  base  already  using  different  versions  and  releases  of  both  stan¬ 
dards 

♦  Use  of  DoD-  or  Federal-  or  industry-specific  implementation  conventions 

♦  Policy  on  the  development  of  implementation  conventions. 

While  it  is  true  today  the  ASC  X12  and  UN/EDIFACT  data  dictionaries  have 
some  differences,  we  believe  that  they  will  be  ameliorated  over  time  as  ASC  X12 
aligns  itself  with  UN/EDIFACT.  This  means  that  we  need  to  determine  where 
dictionary  commonalty  is  necessary. 

The  DoD  and  eventually  the  Federal  government  must  develop  a  policy  of 
EDI  version  and  release  control.  A  policy  of  supporting  the  current  version  and 
back  two  versions  h£is  been  mentioned  as  a  likely  candidate.  While  still  causing 
some  configuration  control  problems,  such  a  policy  woxild  appeal  to  a  wider 
base  of  trading  pcutners. 

It  seems  to  us  that  DoD  and  eventually  the  Federal  government  should  settle 
on  a  version  and  release  and  use  it  for  as  long  a  period  of  time  as  possible. 

One  way  to  deal  with  the  installed  base  issue  is  to  work  with  ASC  X12  to  de¬ 
velop  a  set  of  guidelines  and  tutorials  for  selected  transaction  sets.  In  that  way, 
DoD  will  get  the  private  sector  involved  in  the  process  of  determining  how  stan¬ 
dards  eire  to  be  used.  The  result  would  be  implementation  conventions  devel¬ 
oped  with  wider  input  and  conventions  that  ought  to  be  more  palatable  to  a 
wider  range  of  potential  trading  partners. 

The  DoD  will  also  have  to  rethink  the  timing  of  its  EDI  initiatives.  The 
President's  desire  to  have  some  EDI  up  and  running  by  September  1994  needs  to 
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be  factored  into  other  planning  milestones  to  ensure  that  all  EDI  initiatives  are 
working  from  a  common  set  of  implementation  plans  and  schedules. 

Finally,  DoD  needs  to  ensure  that  its  data  requirements  are  articulated  in 
Federal  implementation  conventions.  Separate  conventions  would  no  longer  be 
needed  for  the  commonly  used  transaction  sets  as  long  as  the  conventions  were 
built  at  the  Federal  level  to  a  greatest  common  denominator  of  the  data  require¬ 
ment.  Department-specific  conventions  should  only  be  used  when  the  use  of  the 
transaction  set  is  unique  to  the  department.  Other  than  that  one  situation,  all 
DoD  conventions  should  migrate  to  Federal  conventions. 


Support  for  Standards-Making  Bodies 

Members  of  standards-making  bodies  believe  that  attendance  ensures  their 
requirements  will  be  met.  The  standards-making  process  is  often  quite  accom¬ 
modating  to  those  who  are  present  to  articulate  their  business  needs.  On  the 
other  hand,  those  who  allow  others  to  develop  the  standards  and  hope  to  be  able 
to  use  them  run  the  risk  that  the  results  will  not  be  acceptable. 

The  DoD  must  commit  resources  to  support  the  standards-making  process. 
That  process  is  voluntary,  and  volimteers  tend  to  support  the  process  out  of  a 
need  to  protect  their  business  interests.  DoD  should  do  likewise.  It  can  optimize 
its  presence  by  volunteering  for  the  following: 

♦  ASC  X12  meetings.  These  meetings  will  be  especially  important  when  the 
business  of  ASC  X12  shifts  from  the  development  of  national  standards  in 
ASC  X12  S5mtax  to  developing  them  in  UN/EDIFACT  syntax. 

♦  Pan  American  EDIFACT  Board  (PAEB)  meetings.  These  semiannual  meet¬ 
ings  are  the  first  stop  as  UN/EDIFACT  syntax-based  messages  migrate  from 
the  national  body  (ASC  X12)  into  the  international  standards-setting  arena. 

♦  Joint  Rapporteurs  meetings.  At  these  semiannual  meetings,  international 
EDI  standards-making  issues  are  resolved. 


Priority  of  EDI  Migration 

An  LMI  report  examined  areas  of  EDI  opportunity  in  DoD^  The  report  con¬ 
cluded  that  procurement  (including  the  finance  function),  transportation,  supply, 
and  maintenance  afforded  the  greatest  near-term  EDI  potential,  with  procure¬ 
ment  possessing  the  greatest  overall  potential  for  using  EDI.  We  believe  the  con¬ 
clusion  of  that  report  remains  valid  today. 

In  that  regard,  DoD  should  focus  initially  on  ensuring  that  procureinent 
functions  can  be  accommodated  in  UN/EDIFACT  messages.  Our  limited 

*LMI  Report  DL001-06R1,  A  Business  Case  for  Electronic  Commerce,  Thomas  P. 
Hardcastie,  Thomas  W.  Heard,  et  al.,  September  1990. 
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research  in.  that  area  suggested  that  the  major  business  functions  associated  with 
the  procurement  process  have  corollary  messages  in  the  UN/EDIFACT  stan¬ 
dards.  Those  messages  should  be  the  first  ones  to  be  assessed  and  used. 

As  a  close  second  priority,  standardization  and  harmony  offer  a  great  poten¬ 
tial  for  using  UN/EDIFACT.  We  suggest  DoD  focus  its  attention  in  that  area  eis 
wen.  Emphasis  should  be  given  to  an  international  effort  to  standardize  logistics 
support. 

Business  ftmctioixally  should  always  be  considered  in  light  of  the  concept  of 
the  extended  enterprise  that  wiU  lead  to  the  integration  of  defense  and  private- 
sector  logistics  into  a  single  relationship.  EDI  facilitates  the  concept  of  extended 
enterprise  and  thus,  the  more  trading  partners  that  DoD  can  acquire  by  trading 
in  both  ASC  X12  and  UN/EDIFACT  syntaxes,  the  greater  the  expansion  of  the 
enterprise.  That  in  turn  will  benefit  readiness,  standardization,  harmonization, 
and  interoperability  in  the  public  and  private  sector  at  home  and  abroad. 

The  DoD  already  knows  which  functional  areas  of  opportunity  afford  the 
greatest  return  on  its  EDI  investment.  For  the  most  part,  those  areas  are  part  of 
tile  acquisition  process  to  include  finance.  The  fimctions  of  transportation,  sup¬ 
ply,  maintenance,  and  material  management  also  present  opportunities  for  econ¬ 
omy  and  efficiency.  For  that  reason,  any  comparison  of  standards  must  tcike  into 
account  the  types  of  business  processes  that  will  have  to  be  accommodated  and 
the  priority  &at  should  be  assigned  to  their  migrating  to  EDI. 

The  DoD  has  laimched  EDI  initiatives  that  suggest  it  intends  to  follow  the 
priorities  established  in  the  business  ceise  previously  cited^  and  refocused  in  De¬ 
fense  Management  Report  Decision  (DMRD)  941  as  modified. 


Estimated  Workload 

Workload  is  not  in  and  of  itself  dependent  upon  which  EDI  standard  DoD 
uses.  Generally,  the  same  effort  is  needed  to  trade  in  ASC  X12  as  to  trade  in 
UN/EDEFACT.  However,  if  DoD  agrees  to  support  both  ASC  X12  and 
UN/EDIFACT  using  trading  partners,  it  will  have  to  maintain  two  standzurds  for 
a  period  of  time.  To  do  so,  will  result  in  some  additional  workload,  which  wiU 
likely  be  offset  by  the  economies  and  efficiencies  that  result  from  exchanging 
data  with  a  larger  base  of  trading  partners. 

Before  estimating  the  workload  involved  in  migrating  to  UN/EDIFACT,  we 
must  determine  the  estimated  workload  involved  in  migrating  to  any  form  of 
EDI.  For  example,  DoD  cannot  do  any  form  of  EDI  without  a  system,  application 
programs,  telecommunications  interconnectivity,  configuration  mcinagement  and 
control,  policy,  priorities,  etc.  The  investment  cost  of  these  items  wiU  change  lit¬ 
tle  regardless  of  which  EDI  standards  are  used  or  even  if  both  are  used  simulta¬ 
neously  for  a  period  of  time. 


*Ibid. 
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Although  we  did  not  include  cost  analysis  of  the  workload,  we  can  make 
some  cost  predictions  based  on  similar  efforts  in  the  ASC  X12  envirorunent.  Our 
estimates  of  the  workload  involved  in  accomplishing  tasks  in  those  general  areas 
is  presented  in  Table  2-2.  These  data  do  not  take  into  account  the  approximate 
$26  million  identified  in  the  acquisition  reform  process  action  team  report. 

We  made  no  attempt  to  segregate  relative  costs  for  adopting  ASC  X12  versus 
UN/EDIFACT,  when  we  believed  the  cost  to  be  the  same  regardless  of  which 
standard  was  adopted.  We  did  isolate  specific  costs  associated  with  the  migra¬ 
tion  to  UN/EDEFACT  diat  can  be  attributed  exclusively  to  that  effort.  Those 
costs  fell  into  seven  general  areas  as  outlined  in  Table  2-2. 


Table  2-2. 

Estimated  Workload  Involved 
in  Migrating  to  UN/EDIFACr 


Task 

Cost/workload 

Business  functionality 

Translation  software* 

Translation  programming  support 
Standards-making  process 

Project  support 

Implementation  convention  development 
Application  programming  support 

1  labor  year 

$250,000  (initial  investment) 

1  labor  year** 

1/2  labor  year/year 

1/2  labor  year/year 

3  labor  years 

2  labor  years®''’ 

Note:  Direct  estimates  for  cost  or  effort  not  otherwise  associated  with  migrating  to  EDI. 


*To  support  a  DoD  concept  of  shared  translation  service  as  opposed  to  translation  at 
data  origination  locations. 

initial  requirement.  After  some  UN/EDIFACT  implementation,  this  number  will  be  re¬ 
duced  to  1/2  labor  year  for  awhile  and  then  to  a  maintenance  level. 

^Associated  with  UN/EDIFACT-based  applications. 

*We  are  also  aware  of  cost  projections  in  the  r)eighborhood  of  $26  million  contained  in  a 
report  on  DoD  acquisition  reform.  Those  costs  are  syntax-neutral  and  would  have  to  be 
expended  regardless  of  which  standard  is  selected. 


Conclusion 

Table  2-3  describes  DoD  readiness  to  migrate  to  UN/EDIFACT  in  terms  of 
colors.  Green  indicates  the  category  is  ready  now,  zunber  indicates  some  move¬ 
ment  toward  readiness,  and  red  indicates  little  or  no  current  readiness.  No  cate¬ 
gory  was  rated  green- 
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Table  2-3. 

DoD  Readiness  to  Migrate  to  UN/EDIFACT 


Category 

Readiness 

Policy 

Red 

Trading  partners 

Amber 

Systems 

Amber 

Architecture 

Amber 

Hardware 

Amber 

Telecommunications  interconnectivity 

Amber 

Applications  programming 

Amber 

Translation  software 

Red 

Support  infrastructures 

Amber 

Business  functionality 

Amber 

Efficiency 

Amber 

Availability  of  messages 

Amber 

Ability  to  pass  transparent  data 

Amber 

Electronic  registration  of  trading  partners 

Red 

Trading  partner  agreement 

Amber 

Trading  partner  capabilities 

Amber 

Configuration  control  of  standards 

Red 

Configuration  control  of  implementation  conventions 

Red 

Changes  to  law,  rule,  and  regulation 

Amber 

Support  for  standards-making  bodies 

Amber 

Security  and  electronic  signatures 

Amber 

Priorities 

Amber 

Budget 

Amber 

Note:  Green  =  ready;  amber  =  some  readiness;  red  =  littie  or  no  current  readiness. 
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Chapter  3 

Comparison  of  ASC  X12 
and  UN/EDIFACT 


This  chapter  provides  a  comparison  of  ASC  X12  and  UN/EDEFACT  stan¬ 
dards,  including  the  standards-making  organizations,  standards-making  proce¬ 
dures,  and  structural  differences.  Appendix  A  describes  standards  organizations 
and  procedures  in  greater  detail,  and  Appendix  B  covers  selected  structural  and 
other  differences  between  the  ASC  X12  and  UN/EDEFACT  standards. 


Organizations 

Accredited  Standards  Committee  X12 

The  ASC  X12  has  a  formal  organizational  structure  designed  to  facilitate  the 
consensus-building  process  leading  to  the  development  and  publication  of  drctft 
standards  for  trial  use  (DSTUs)  and  subsequently  ANSI  EDI  standeirds. 

Most  development  work  on  ASC  X12  standards  is  done  at  the  subcommittee 
level,  and  most  subcommittees  are  functionally  oriented  (e.g..  Purchasing  and 
Material  Management),  with  one  notable  exception,  the  Government  Subcommit¬ 
tee.  That  subcommittee  is  chartered  to  develop  standards  when  one  or  both  peir- 
ties  exchanging  information  tire  government  entities. 

Not  edl  development  work  meeting  the  one-or-both-party  test  is  done  in  the 
Government  Subcommittee.  Often,  because  of  the  functions  involved  in  the 
work  (i.e.,  changes  to  an  existing  transaction  set  that  was  designed  by  another 
subcommittee),  a  standard  affectog  the  government  is  assigned  to  the  subcom¬ 
mittee  that  developed  the  transaction  set.  DoD  has  worked  closely  with  a  num¬ 
ber  of  ASC  X12  subcommittees  and  continues  to  do  so  in  an  effort  to  ensure  its 
business  functionality  is  included  in  ASC  X12  standards. 

The  Government  Subcommittee  has  completed  a  substantial  amount  of  stan¬ 
dards  development  work  for  DoD  as  well  as  otiier  Federal  agencies  (e.g., 
U.S.  Customs  Services,  Federal  Communications  Commission,  etc.). 

The  ASC  X12  organization  tends  to  be  reasonably  stable.  A  summary  of  the 
current  ASC  X12  organizational  structure  is  shown  in  Appendix  A. 

A  private  company.  Data  Interchange  Standards  Association,  Inc.,  serves  as 
the  ASC  X12  Secretariat. 
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UN/EDIFACT 


A  formal  organizational  structure  has  been  designed  to  facilitate  the 
consensus-building  process  leading  to  the  development  and  publication  of 
UN/EDIFACT  standards.  Development  work  on  UN/EDIFACT  standards  in 
the  United  States  typically  starts  at  the  ASC  X12  subcommittee.  In  the  case  of 
DoD,  the  Government  Subcommittee  would  be  responsible  for  the  work  in  most 
cases.  In  other  cases,  the  Government  Subcommittee  would  likely  defer  to  an¬ 
other  subcommittee  when  the  development  work  was  initially  done  by  that  sub¬ 
committee  or  the  business  functionality  was  clearly  within  ^t  subcommittee's 
area  of  expertise  and  responsibility.  For  example,  if  DoD  wants  to  add  some 
business  functionality  to  the  UN/EDIFACT  ORDERS  (i.e.,  purchase  order)  mes¬ 
sage,  that  work  would  likely  be  undertaken  by  the  ASC  X12  Purchasing  Subcom¬ 
mittee. 

The  Government  Subcommittee  has  an  organic  capability  to  assist  in  the  de¬ 
velopment  of  standards  using  UN/EDIFACT  syntax.  That  capability  is  inherent 
in  the  mission  of  ASC  X12  which,  in  addition  to  developing  standards  in 
ASCX12  syntax,  entails  serving  as  the  national  developer  of  standards  in 
UN/EDIFACT  syntax.  The  Government  Subcommittee  has  already  done  a  sub¬ 
stantial  amount  of  UN/EDIFACT  standards  development  work  for  U.S.  Customs 
Services,  and  as  a  result.  Government  Subcommittee  members  are  well-versed  in 
the  design  and  maintenance  of  UN/EDIFACT  standards. 

Entry  into  the  UN/EDIFACT  arena  from  ASC  X12  is  through  the  Pan 
American  EDIFACT  Board  (PAEB),  covered  in  more  detail  in  Appendix  A.  Ap¬ 
pendix  A  also  provides  a  sununary  of  the  present  UN/EDIFACT  organizational 
structure. 

A  private  company.  Data  Interchange  Standards  Association,  Inc.,  serves  as 
the  PAEB  Secretariat. 


Procedures 

ASCX12 


Procedures  followed  by  ASC  X12  in  developing  and  maintaining  EDI  stan¬ 
dards  may  appear  to  be  long,  complex,  labor-intensive,  and  often  times,  convo¬ 
luted  to  those  persons  just  becoming  involved  in  the  process.  Notwithstanding, 
those  procedures  are  more  easily  understood  as  they  are  used,  and  they  are  nec¬ 
essary  for  consensus  building,  the  cornerstone  of  the  standards-development 
process.  Appendix  A  contains  a  general  description  of  the  procedure  used  to  ob¬ 
tain  approvd  of  a  new  standard  or  change  an  existing  standard. 
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UN/EDIFACT 


Development  of  UN/EDIFACT  standards  faces  essentially  the  same  hurdles 
as  those  required  for  the  development  of  ASC  X12  standards.  Because 
UN/EDIFACT  standards  are  international,  the  standards-making  process  in¬ 
cludes  more  steps  than  does  the  making  of  a  national  standard.  Appendix  A 
presents  a  general  description  of  the  procedure  used  to  obtain  approval  of  a  new 
UN/EDIFACT  standard. 


Structural  Differences  Between  ASC  X12 
AND  EDIFACT 


General 


Originally,  UN/EDIFACT  used  ASC  X12  for  its  standards  design  guidance. 
The  design  of  the  first  UN/EDIFACT  message  duplicated  many  aspects  of 
ASCX12  transaction  sets.  That  procedure  enabled  UN/EDIFACT  to  start 
quickly,  but  it  copied  ASC  X12  problems  as  well.  At  a  point  in  time, 
UN/EDIFACT  began  to  follow  its  own  message  design  philosophy  and  resolved 
many  perceived  problems  with  ASC  X12  by  incorporating  such  things  as  generic 
data  elements,  composites,  the  single  date/  time  solution,  and  data  segment  clari¬ 
fication  descriptions  as  part  of  its  message  design.^  Appendix  B  presents  a  more 
detailed  discussion  of  selected  structur2d  differences  between  ASC  X12  and 
UN/EDIFACT  standards. 

While  some  of  the  terminology  differs  between  the  standards,  both  contain 
comparable  building  blocks.  Each  standard  uses  the  data  element  as  its  funda¬ 
mental  building  block.  Data  elements  carry  data  characterized  as  numbers, 
amounts,  quantities,  code  values,  text,  and  the  like.  Data  elements  are  grouped 
together  in  logical  arrangements  to  convey  related  business  information.  That 
grouping  of  data  elements  is  known  as  a  segment.  A  message  in  UN/EDIFACT 
(or  transaction  set  in  ASC  X12  language)  is  made  up  of  a  series  of  segments  ar¬ 
ranged  in  a  logical  order  to  facilitate  the  flow  of  data  to  and  from  application 
programs. 

Both  standards-making  bodies  learned  at  the  outset  of  their  efforts  that  they 
had  to  develop  standards  to  support  that  business  functionality  that  afforded 
trading  partners  the  greatest  return  for  their  investment.  In  that  regard,  the  pro¬ 
curement,  transportation,  product  data,  and  material  management  areas  have 
been  reasonably  well  covered  in  both  standards.  ASC  X12  transaction  sets  are 
compared  to  UN/EDIFACT  messages  in  Appendix  B.  While  that  comparison 
does  not  include  the  respective  business  functionality,  it  does  provide  an  indica¬ 
tion  that  both  standards-making  bodies  have  made  an  effort  to  develop  stan¬ 
dards  in  the  zireas  that  will  also  be  of  primary  interest  to  DoD.  A  more  detailed 


’  Briefing  entitled  EDIFACT:  The  Next  Generation  of  EDI  Messages  given  by  Klaus- 
Dieter  Naujok  at  several  ASC  X12  trimester  meetings. 
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discussion  of  the  similarities  between  the  two  standards  can  be  found  in  Appen¬ 
dix  B. 


Data  Elements 


Data  elements  are  the  basic  units  of  information  in  either  an  ASC  X12  or  a 
UN/EDEFACTT  transmission.  They  are  often  generic  and  their  precise  meanings 
may  be  determined  by  the  context  of  the  segment  in  which  they  are  used  or  by 
additional  qualifier  data  elements. 

Data  elements  in  both  standards  are  identified  as  simple,  component,  or  com¬ 
posite.  A  simple  data  element  occurs  in  a  segment  outside  the  defined  boundaries 
of  a  composite  data  structure.  A  component  data  element  is  a  simple  data  element 
that  ocau’s  as  a  positioned  member  of  a  composite  data  structure.  A  composite 
data  element  (or  structure)  is  a  group  of  two  or  more  component  (or  simple)  data 
elements  linked  togefiier  to  form  a  single  data  element.  (Appendbc  B  clarifies  the 
types  of  data  elements  and  presents  a  detailed  discussion  of  the  structural  differ¬ 
ences  between  ASC  X12  data  elements  and  UN/EDIFACr  data  elements.) 

Because  of  the  generic  approach  using  qualifiers,  UN/EDIFACT  has  more 
than  100  composites  compared  to  only  a  few  currently  used  in  ASC  X12. 


Segments 

Segments  are  the  intermediate  units  of  information  in  transaction  sets  and 
messages.  They  comprise  a  unique  segment  identifier;  one  or  more  composite 
data  structures  or  simple  data  elements,  each  preceded  by  a  data  element  separa¬ 
tor;  and  a  segment  terminator. 

The  major  difference  between  UN/EDIFACT  and  ASC  X12  is  that 
UN/EDIFACfr  attempts  to  use  a  "generic"  solution  in  message  design  as  op¬ 
posed  to  ASC  X12,  which  sometimes  uses  a  "specific"  approach.  In  the  generic 
approach,  the  same  segment  can  be  used  for  many  specific  values.  Thus, 
ASCX12  occasionally  uses  "long"  segments  containing  many  data  elements, 
while  UN/EDIFACT  uses  shorter  segments  in  greater  numbers  in  their  mes¬ 
sages. 


Transaction  Sets/ Messages 

A  message  or  transaction  set  is  a  set  of  segments  in  the  order  specified  in  a 
directory.  A  UN/EDEFACT  standard  message  (UNSM)  is  one  that  has  been  ap¬ 
proved,  published,  and  maintained  by  the  UN.  An  ASC  X12  standard  is  gener¬ 
ally  referred  to  as  a  draft  standard  for  trial  use  (DSTU).  Upon  approval,  DSTUs 
become  ANSI  standards. 


Transaction  set  designers  often  ask  for  very  specific  segments  to  facilitate  the 
flow  of  information  into  and  out  of  application  programs.  Granting  of  those  re¬ 
quests  resulted  in  ASC  X12  having  much  larger  numbers  of  segments  and  data 
elements  than  UN/EDIFACT.  In  UN/EDIFACT,  message  designers  tend  to  re¬ 
peat  the  same  segment  but  ask  for  new  code  values  to  be  added  to  qualifier  code 
lists. 


In  UN/EDIFACT,  segments  are  combined  into  segment  groups.  That  ap¬ 
proach  has  the  advantage  of  not  using  a  particular  segment  if  it  is  not  needed 
during  a  certain  transmission;  in  the  ASC  X12  "long-segment"  approach,  one 
might  need  to  skip  a  large  number  of  data  elements  before  using  the  one  at  the 
end  of  a  segment.  UN/EDIFACT  also  uses  only  one  generic,  beginning-of- 
message  segment,  whereas  ASC  X12  currently  has  60  specific  beginning-of- 
transaction  set  segments. 

Proponents  of  UN/EDIFACT  point  to  ASC  X12  as  having  too  many  begin¬ 
ning  segments  zmd  too  many  ways  to  transmit  dates  as  evidence  of  inefficiency. 
We  believe  the  argument  has  merit  only  to  the  extent  that  ASC  X12  is  a  larger 
standard  to  maintain.  With  ever-increasing  transmission  speeds  and  innovations 
in  data  compression,  the  size  of  one  transmission  versus  the  other  appears  to  be 
relatively  insignificant. 


Conclusion 

The  ASC  X12  and  UN/EDIFACT  standcurds  are  similar  in  some  aspects  and 
different  in  others.  The  differences  are  not  deemed  to  be  peirticularly  relevant  to 
a  discussion  of  the  readiness  of  DoD  to  migrate  to  UN/EDIFACT. 

We  find  that  the  standards-making  process  always  accommodates  business 
functionality  issues.  The  UN/EDIFACT  development  process  has  always  re¬ 
sulted  in  a  solution  for  business  functionality,  and  while  a  developer  may  not  be 
happy  with  aU  solutions  {as  in  the  case  of  transparent  data),  a  solution  has  eil- 
ways  been  provided.  We  fully  expect  that  situation  to  continue  when  DoD 
brings  its  business  functionality  to  the  UN/EDIFACT  development  table. 


3-5 


Chapter  4 

Recommendations 


This  chapter  provides  our  recommendations  and  a  suggested  strategic  direc¬ 
tion  for  migration. 


General 


The  DoD  should  adopt  a  "one  world  —  one  EDI  standard"  policy,  with  that 

standard  being  UN/EDIFACT.  To  put  that  policy  into  practice,  DoD  must  take 

the  following  steps: 

♦  Allow  market-place  and  resource  constraints  to  dictate  the  timing  and  the 
additional  use  of,  and  eventual  complete  migration  to,  UN/EDIFACT  stan¬ 
dards 

♦  In  the  near  term,  continue  to  trade  using  ASC  X12  standards 

♦  Add  the  ability  to  support  UN/EDIFACT  standards  to  the  technical  infra¬ 
structure 

♦  Participate  in  the  UN/EDIFACT  standards-development  process  and  ensure 
business  functionality  is  contcdned  in  UN/EDIFACT  standards 

♦  Support  Trading  Partners  using  either  the  ASC  X12  or  UN/EDIFACT  stan¬ 
dards 

♦  Support  UN/EDIFACT-based  pilot  projects  to  build  early  experience,  dem¬ 
onstrate  commitment,  and  evaluate  impacts. 


Strategic  Direction 

Like  any  other  endeavor,  DoD  should  migrate  to  UN/EDIFACT  through 
careful  planning  and  meaningful  execution  of  the  plan,  hr  that  regard,  DoD 
needs  to  take  the  following  steps: 

♦  Use  these  recommendations  as  the  DoD  strategic  plan  for  migration  to 
UN/EDIFACT. 

♦  Support  the  strategic  plan  with  an  implementation  plan  detailing  the  spe¬ 
cific  tasks  involved  in  the  migration  to  UN/EDIFACT.  That  plan  must 
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contain  a  list  of  milestone  actions  in  chronological  order  based  on  the  fol¬ 
lowing: 

►  Estimated  time  to  complete 

►  Priorities 

►  Availability  of  funding 

►  Assignment  of  responsibilities  for  all  listed  actions. 

On  the  technical  side,  DoD  must  size  the  emerging  DoD  and  Federal  EDI 
systems  for  maximum  flexibility  and  ensure  the  capability  of  supporting  both 
ASC  X12  and  UN/EDIFACT  standards. 

In  the  area  of  migration  control,  DoD  must  take  the  following  additional 
steps: 

♦  Achieve  central  control  over  existing  and  potential  EDI  projects  within  DoD 
and  allow  decentralized  execution  of  the  EDI  program 

♦  Become  involved  m  the  ASC  X12  and  EDEFACT  standards-making  process. 

The  DoD  can  gain  some  immediate  and  practical  experience  in  the  use  of 
UN/EDIFACT  standards  by  initiating  projects  in  two  specific  areas; 

♦  Harmonization  of  international  logistics 

♦  Overseas  procurement 

We  recommend  that  DoD  continue  to  trade  and  expand  its  trade  with  part¬ 
ners  using  ASC  X12  standards  while  allowing  the  market-place  and  resource 
constraints  to  dictate  the  additional  use  of,  and  eventual  complete  migration  to, 
EDIFACT  standards.  To  this  course  of  action,  we  add  the  need  to  gain  some  im¬ 
mediate  experience  in  the  use  of  UN/EDIFACT  standards. 

Figure  4-1  covers  at  a  macro  level  a  suggested  time  line  for  the  major  activi¬ 
ties  necessary  to  migrate  to  UN/EDIFACT. 
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Action 

FY94 

FY95 

FY96 

1st 

Qtr 

2nd 

Qtr 

3rd 

Qtr 

4th 

Qtr 

1st 

Qtr 

2nd 

Qtr 

3rd 

Qtr 

4th 

Qtr 

1st 

Qtr 

2nd 

Qtr 

3rd 

Qtr 

4th 

Qtr 

Articulate  a  UN/EDIFACT 
strategy 

■ 

■ 

Develop  implementation  plan 

Size  DoD  EDI  infrastructure 

Establish  telecommunication 
interconnectivity 

A 

■ 

■ 

■ 

■ 

Ensure  DoD  Business 
functionality  is  contained  in 
UN/EDlFACT  standards 

■ 

■ 

■ 

■ 

Activate  Architecture 

■H 

Participate  fully  In 
UN/EDIFACT  standards 
development 

■ 

■ 

■ 

m 

m 

Complete  development  of 
appplication  program 

A 

■■■I 

■■■ 

■■■1 

■■■■ 

■■■1 

■■■■ 

Achieve  central  control  over 
UN/EDIFACT  projects 

A 

IHIigB 

■■■■ 

HHi 

Form  a  UN/EDIFACT  users 
group 

A 

■ 

■ 

Begin  to  implement 
UN/EDIFACT  EDI 

m 

■ 

■ 

■ 

Develop  UN/EDIFACT 
implementation  conventions 

Figure  4-1. 

UN/EDIF ACT  Migration  Strategy  —  Milestone  Chart 
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Appendix  A 


Standards-Making  Organizations 

and  Procedures 


Standards-Making  Organizations 
and  Procedures 


The  American  National  Standards  Institute  (ANSI)  Accredited  Standards 
Committee  (ASQ  X12  and  the  United  Nations  Electronic  Data  Interchange  for 
Administration,  Commerce,  and  Transport  (UN/EDIFACT)  both  have  formally 
structured  organizations  and  procedures  with  which  to  monitor,  administer,  and 
process  activities.  This  appendix  presents  a  description  of  these  two 
organizations  -  ASC  X12  and  UN/EDIFACT  —  and  a  discussion  of  the  respec¬ 
tive  procedures  and  processes  used  by  each. 


ASC  X12  Organization 

American  National  Standards  Institute 

The  ANSI  was  fouuided  in  1918  as  the  national  coordinator  for  standards  in 
the  United  States.  ANSI  provides  an  open  forum  for  all  concerned  interests  to 
identify  standards  needs,  plan  to  meet  those  needs,  2md  agree  on  standards. 

In  addition,  ANSI  coordinates  the  volunteuy  development  of  national  con¬ 
sensus  standards,  approves  standards  as  American  National  Standards,  and 
serves  as  a  clearinghouse  and  information  center  for  American  national  and  in¬ 
ternational  standards.^ 

In  1979,  it  chartered  a  new  committee,  ASC  X12,  to  develop  uniform  stan- 
dcuds  for  the  electronic  interchange  of  business  transactions.^  Figure  A-1  shows 
the  organization  of  ASC  X12. 

The  ASC  X12  is  the  decision-making  body  responsible  for  developing  the 
evidence  of  consensus  necessary  for  approval  of  American  National  Standairds. 
Subcommittees  cure  assigned  responsibility  for  specific  standards  development 
and  standards  mciintenance  activities,  but  their  work  must  be  ratified  by  the 
membership  of  ASC  X12.® 

The  ASC  X12  Standing  Document  2:  Operations  Manual  is  the  official  source 
for  information  on  standards-processing  requirements.  To  maintain  its  accred¬ 
ited  committee  status,  ASC  X12  must  follow  these  procedures  to  ensure  compli¬ 
ance  with  the  ANSI  procedures  for  the  development  and  coordination  of 
American  National  Standards. 


’  ASC  X12  Standing  Document  2:  Operations  Manual,  revised  edition,  1993. 

^ASC  X12  Standards,  Draft  Version  3  (003030),  Data  Interchange  Standards  Associa¬ 
tion,  Inc.,  ASC  X12S/92-707,  December  1992. 

^  ASC  X12  Standing  Document  2:  Operations  Manual,  revised  edition  1993. 
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Source:  1993  DISA  Publications  Catalog,  fncorporating  Introduction  to  EDI. 


Figure  A-1. 

ASCX12  Organization 


Data  Interchange  Standards  Association,  Inc.  (DISA) 

The  Data  Interchange  Standards  Association,  Inc.  (DISA)  was  formed  in  1987 
to  be  the  Secretariat  and  administrative  arm  of  ASC  X12.  Its  staff  manages 
membership,  balloting,  international  programs,  standards  maintenemce,  publica¬ 
tions,  the  annual  conference  and  exhibit,  ASC  X12  meetings,  communications 
with  ANSI  on  behalf  of  ASC  X12,  and  other  administrative  duties  required  to 
support  ASC  X12.^ 


ASC  X12  Steering  Committee 

The  Steering  Committee  develops  recommendations  for  the  administration 
of  ASC  X12  in  close  coordination  with  the  Secretariat.  It  is  composed  of  the 
ASC  X12  Committee  Chair,  Vice  Chair,  Subcommittee  Chairs,  and  past  officers. 
The  Steering  Committee  has  several  standing  groups:  Executive  Committee,  Le¬ 
gal  Issues  Task  Group,  Organization  and  Procedures  Task  Group,  and  the 
ASC  X12/EDIFACT  Alignment  Task  Group.® 


*  ASC  X12  Standing  Document  2:  Operations  Manual,  revised  edition,  1993. 
®  ASC  X12  Standing  Doaunent  2:  Operations  Manual,  revised  edition  1993. 
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Procedures  Review  Board 


The  Procedures  Review  Board  (PRB)  has  a  primary  responsibility  to  ensure 
that  due  process  is  followed  before  approval  of  new  project  proposals,  release  of 
documents  for  ASC  X12  membership  ballot,  and  publication  of  standards. 


Pan  American  EDIFACT  Board 

Until  1993,  the  Pan  American  EDIFACT  Board  (PAEB)  was  a  work  group 
within  the  ASC  X12  organization  structure.  Today,  the  PAEB  is  a  separate  entity 
as  shown  in  Figure  A-2.  DISA  serves  as  the  PAEB  Secretariat.  The  Delegate  Liai¬ 
son  Task  Group  consists  of  official  representatives  of  ASC  X12,  drawn  primarily 
from  the  subcommittees,  and  imofficieil  representatives.  The  Technical  Advisory 
Work  Group  provides  technical  assessment  services  to  message  developers  simi- 
lea  to  the  service  provided  by  the  Technical  Assessment  Subcommittee  of 
ASCX12. 


ASC  X12  Standard  Releases 

Since  1986,  by  approval  of  ANSI,  the  ASC  X12  Secretariat  (DISA)  has 
published  a  series  of  versions  and  releases.  Those  documents  represent 
ASC  X12-approved  revisions  of  those  previously  published  American  National 
Standards  and  new  ASC  X12-approved  draft  standards.  ASC  X12's  purpose  in 
publishing  these  versions  and  releases  is  to  put  current  ASC  X12-approved  draft 
standards  into  the  hands  of  users  on  a  more  frequent  schedule.  All  draft  stan¬ 
dards  for  trail  use  (DSTUs)  imdergo  the  ANSI-required  periodic  public  review 
process.® 


ASC  X12  Procedures 

The  ASC  X12  Standing  Document  2:  Operations  Manual  defines  the  operat¬ 
ing  procedures  of  ASC  X12  in  carr5ring  out  its  mission.^  Those  procedures  define 
the  critical  approval  levels  that  must  be  achieved  before  a  document  can  be  pub¬ 
lished  as  an  ASC  X12  DSTU,  an  ASC  X12  interpretation,  an  ASC  X12  guideline, 
or  a  technical  report.  ASC  X12  has  determined  that  its  standards  development 
activities  will  result  first  in  the  approval  of  DSTUs,  which  are  then  considered  for 
American  National  Standard  status  imder  ANSI-defined  procedures*  (see 
Figure  A-3). 


*  ASC  X12  Standards,  Draft  Version  3  (003030),  Data  Interchange  Standards  Associa¬ 
tion,  Inc.,  ASC  X12S/ 92-707,  December  1992. 

^  ASC  X12  Standing  Document  2:  Operations  Manual,  revised  edition,  1993. 

*Ibid. 
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Note:  Kiaus-Dieter  Naujok,  ASC  X12  Trimester  Meeting.  New  Attendee  Orientation,  Awareness  and  Edu¬ 
cation  Task  Group,  Miami,  Florida,  October  1993. 


Figure  A-2. 

Pan  American  EDJPACF  Board  Organization 


The  Operations  Manual  covers  the  following  four  areas: 

1.  Procedures  for  draft  standards  for  trial  use 

a.  Development  procedures 

b.  Maintenance  procedxires 

2.  Procedtires  for  interpretations  development  and  approval  procedures 

3.  Procediu-es  for  X12  guidelines  and  technical  reports 

4.  Procedures  for  American  National  Standards 
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Starting  time 


±5  years 


Note:  Based  on  information  contained  in  ASC  X12  EDI,  Standing  Document  2:  Operations  Manual, 
revised  edition.  1993. 

Figure  A-3. 

ASCX12  Procedures 


UN/EDIFACT  Organization 

The  United  Nations  Economic  Commission  for  Europe  (UN/ECE)  is  one  of 
the  five  major  economic  and  social  commissions  established  by  the  Economic 
and  Social  Council  of  the  United  Nations.  It  embraces  North  American  and  East¬ 
ern  and  Western  Europe.  The  UN/ECE  currently  comprises  34  member  states; 
in  addition,  any  coimtry  that  is  a  member  of  the  United  Nations  2md  has  an  inter¬ 
est  in  a  given  subject  may  participate  in  UN/ECE  meetings.  Certain  approved 
intergovernmental  and  nongovernmental  organizations  may  participate  in  cer¬ 
tain  committees  (see  Figure  A-4). 
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Note;  Based  on  Introduction  to  UN/EDIFACT,  Data  Interchange  Standards  Association,  Inc.,  April  1991. 


Figure  A*4. 

UN  Standards  Organization 


Working  Party 

The  UN/ECE  Working  Party  4  on  Facilitation  of  International  Trade  Proce¬ 
dures  (WP.4)  is  a  subsidiary  body  of  the  Committee  on  the  Development  of 
Trade.  It  comprises  experts  on  data  elements  and  automatic  data  interchange 
(GE.l)  and  experts  on  procedures  and  doounentation  (GE.2),  all  of  whom  are  ap¬ 
pointed  by  dieir  governments  or  by  organizations  recognized  by  the  UN/ECE 
and  UN/EDIFACT  rapporteurs. 


UN/EDIFACT  Rapporteurs 

Individual  governments  nominate  UN/EDIFACT  rapporteurs  and  WP.4  ap¬ 
points  them.  They  are  requested  to  implement  a  common  and  agreed  upon  man¬ 
date  for  a  certain  area  of  jurisdiction.’  The  mandate  is  as  follows: 

♦  To  set  up  a  consultative  machinery 


’The  UN/EDIFACT  Rapporteurs'  Procedures  &  Message  Documentation  Rules. 
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♦  To  establish  the  facilities  required  to  develop,  maintain,  and  implement  the 
UN/ECE  recommendations  on  standards,  as  they  relate  to  syntax,  data  ele¬ 
ments,  segments,  message  design  guidelines,  and  messages 

♦  To  develop  and  offer  technical  assessment  facilities 

♦  To  develop  any  other  appropriate  docmnentation  and  procedtures  to  assist 
in  the  implementation  of  the  UN/ECE  recommendations  on  EDI 

♦  To  provide  coordination  facilities  between  them  and  the  WP.4  secretariat. 

Rapporteur  Advisory  and  Support  Teams  (RTs)  are  appointed  by  UN/ECE 
WP.4  and  represent  Western  Europe,  Eastern  Europe,  Pan- America,  Asia,  Africa, 
and  Australia/New  Zealand.  The  RTs  also  coordinate  maintenance  procedures 
for  the  UN/EDIFACT  syntax  rules  and  the  UN/EDEFACT  directory  sets  with  the 
UN/ECE  secretariat. 

Rapporteurs'  general  duties  include  the  following: 

♦  Implementing  the  WP.4  mandate,  reporting  to  GE.1 

♦  Appointing  the  secretariat 

♦  Holding  joint  meetings  with  other  RTs 

♦  Consulting  with  trade  organizations 

♦  Coordinating  development  of  UN  Standard  Messages  (UNSMs) 

♦  Presenting  written  reports  of  activities,  proposals  on  UNSMs,  and  future 
plans 

♦  Serving  on  joint  development  projects  resulting  from  WP.4  meetings 

♦  Ensuring  agreement  on  content  of  submissions  and  submitting  in  a  timely 
manner 

♦  Preparing  agendas  and  forecasts 

♦  Attending  Joint  Rapporteurs  Team  (JRT)  meetings 

♦  Holding  at  least  two  meetings  a  year 

♦  Publishing  schedules  and  agenda  for  the  meetings 

♦  Ensuring  their  work  groups  are  represented  at  the  biannual  meetings 

♦  Providing  discussion  items  for  the  meetings 
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♦  Distributing  meeting  reports 

♦  Publishing  decisions  ratified  by  RTs. 


Working  Group 


♦ 

♦ 

♦ 

♦ 

♦ 

♦ 

♦ 

♦ 


The  rapporteur  working  group's  duties  include  the  following: 

Following  UN/EDIFACT  procedmes  when  reviewing  work 

Providing  prior  notification  of  delay  to  the  secretariat 

Following  UN /EDIFACT  procedures  when  communicating 

Following  UN /EDIFACT  procedmres  when  participating  in  a  joint  activity 

Confirming  objectives  of  work 

Establishing  timetables 

Agreeing  on  procedures 

Producing  minutes. 


Regional  UN/EDIFACT  Boards 

Regional  UN/EDEFACT  boards  are  appointed  locally  to  support  the  rap 
porteur  in  the  execution  of  his/her  responsibilities.  The  constitution  of  boards  is 
not  regulated  by  WP.4  but  veuies  to  allow  for  regional  differences  in  geography, 
language,  and  political  environment.  The  boards  also  provide  a  forum  for  re¬ 
gional  representation  and  consensus  to  tiie  rapporteur.  Boards  coordinate  mes¬ 
sage  development,  technical  assessment,  maintenance,  and  documentation  and 
promote  UN/EDEFACT  standards. 


Joint  Rapporteurs  Meetings 

Twice  a  year,  the  rapporteurs  meet  in  joint  session  (JRT  meetings)  to  provide 
a  forum  at  which  UN/EDIFACT  bodies  meet  to  coordinate  regional  positions 
into  international  standards,  JRT  meetings  are  not  part  of  the  direct  standards- 
development  or  education  process.  Instead,  diey  provide  a  forum  for  consensus 
building.  The  organization  supporting  the  rapporteurs  is  shown  on  Figure  A-5, 
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Rapporteurs 


Steering  Committee 


Ad  Hoc 
Committees 


Messages 

—  Purchasing 

—  Transport 

—  Banking 

—  Insurance 

—  Products  and  Quality 

—  Materia!  management 
”•  Statistics 

—  Trave!,  Tourism,  and  Leisure 
Customs 


Technical 

—  Joint  technical  assessment 

—  Joint  Maintenance  agency 

—  Code  &  Data  Element 
Maintenance 
Interactive  EDI 

—  Security 

—  Syntax  Development  Group 


Support 

—Awareness  &  Education 

—  Procedures  &  Documentation 

—  UNSM  User  Implementation 

—  Guidelines 
^  Secretaries 


Note:  Kiaus-Dieter  Naujok,  A5C  X12  Trimester  Meeting,  New  Attendee  Orientation,  Awareness  and  Eduh 
cation  Task  Group,  Miami,  Florida,  October  1993. 

Figure  A-5. 

JRT  Meeting  Organization 


UN/EDIFACT  Procedures 

The  UN/EDIFACr  procedures  govern  the  development  of  UNSMs  and  their 
associated  directories  and  documentation.  They  also  include  change  requests 
and  conformance  analysis  procedures.  These  procedures  should  be  used  by  or¬ 
ganizations  wishing  to  propose  UNSM  development  or  changes  to  existing  mes¬ 
sages  or  their  components.  The  working  language  for  UN/EDIFACT  is  English, 
and  six  standard  procedures  are  defined  within  UN/EDIFACT  procedures: 

♦  New  UNSM  development 

♦  Formal  changes 
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♦  Code  requests 

♦  Informal  document  circulation 


♦  Informal  changes 


♦  Conformance  analysis. 


Format  charige/oode 
request  procures 


Note:  Based  on  forma!  and  informal  presentations  at  various  UN/EDIFACT  sessions. 


Figure  A-6. 

UN/EDH ACT  Procedures 


Messages  and  directories  are  given  certain  "status"  once  approved  within 
the  UN/ECE  (see  Figure  A-6).“ 

♦  Status  0  —  draft  dooiment 

►  Rapporteur  establishes  a  working  group  for  single  or  joint  message  de¬ 
velopment 

►  Work  is  progressing  but  has  not  reached  an  advanced  stage.  It  is  sub¬ 
mitted  to  WP.4  for  information  only. 

►  Working  group  agrees  the  message  is  ready  for  Status  0. 

►  Request  for  Status  0,  including  necessary  forms  and  docmnentation,  is 
sent  to  regional  technical  assessment  group. 

’“The  UN/EDIFACr  Message  Design  Guidelines. 
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Conformance  to  standards  assessed  and  guidance  provided. 


►  If  conformance  to  standards  is  achieved,  regional  secretariat  assigns 
Status  0  and  forwards  copies  of  the  developmental  work  to  the  other  re¬ 
gions  and  to  WP.4  secretariat. 

►  Regions  not  participating  in  the  development  have  6  months  in  which 
to  provide  comments  on  the  Status  0  message. 

♦  Status  1  —  draft  recommendation.  The  docmnent  has  been  approved  for 

trial  use.  The  steps  leading  to  Status  1  are  as  follows: 

►  If  all  regions  approve  the  development,  the  controlling  rapporteur  rec¬ 
ommends  Status  1  to  WP.4. 

►  If  all  regions  oppose  the  development,  the  rapporteur  can  recommend 
to  the  developer  that  the  message  be  withdrawn. 

►  If  the  regions  are  divided  in  their  opinions,  the  rapporteur  has  the  fol¬ 
lowing  options: 

♦  Re-enter  the  development  after  making  modifications  suggested  by 
dissenting  regions 

♦  Submit  the  work  to  WP.4  with  a  notice  that  unanimity  cannot  be 
reached 

♦  Recommend  to  the  developer  that  the  message  be  withdrawn 

♦  Stand  aside.  (The  requester  can  appeal  the  decision  if  Status  1  is 
not  granted.) 

►  Decisions  on  status  rest  with  WP.4. 

♦  WP.4  can  eissign  Status  1,  reassign  Status  0,  or  approve  the  with¬ 
drawal  of  the  development  request. 

♦  If  approved,  the  secretariat  will  add  the  Status  1  message  to  the 
trial  directories  and  within  a  month  of  the  decision,  notify  the  de¬ 
veloper  of  the  decision  to  grant  Status  1. 

♦  Upon  notification,  the  user  community  can  test  the  message  on  a 
trial  basis  for  at  least  12  months. 
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♦  Status  2  —  recommendation.  The  document  has  been  approved  by  WP .4  as 
a  formal  recommendation  and  registered  as  a  United  Nations  Standard  Mes¬ 
sage.  It  is  ready  for  full  implementation.  The  steps  leading  to  Status  2  are  as 
follows: 

►  After  the  trial  period  ends,  all  rapportexirs  send  comments  to  the  sup¬ 
porting  secretariat. 

►  Status  1  approval  procedures  are  repeated  for  Status  2. 

►  If  approved  by  WP.4,  the  message  becomes  Status  2  and  WP.4  publishes 
it  as  a  UNSM. 

As  each  document  changes  status,  it  may  be  revised.  To  ensure  precise  iden¬ 
tification,  the  front  page  of  each  document  carries  the  full  title  and  a  reference  to 
its  status,  the  revision  number,  and  the  date  of  issue  in  the  International  Stan¬ 
dards  Organization  (ISO)  format,  e.g.  93-09-20.  The  revision  number  starts  at  0 
(zero)  indicating  the  first  issue  of  the  document.  For  example.  Message  Design 
Guidelines  S2R2  would  indicate  that  the  status  of  the  document  was  at  the  level 
of  a  recommendation  and  that  it  was  in  Revision  2;  Letter  of  Credit 
Message  S0R4  would  indicate  that  its  status  was  that  of  a  draft  document  and 
that  it  was  in  Revision  4. 

The  ISO  9735  document  (UN/EDIFACT  Syntax  Rules)  provides  for  version/ 
release  numbers  to  be  used  in  the  UNH  or  UNG  service  segments.^^  The  UN 
uses  three  procedures  for  the  unique  identification  of  messages,  one  for  UNSMs, 
one  for  messages  that  have  reached  Status  1,  and  one  for  messages  at  Status  0. 


’’  UNH  is  code  for  UN/EDIFACT  message;  UNG  is  code  for  UN/EDIFACT  functional 
group  header. 
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Appendix  B 


Differences  Between  ASC  X12  Standards 

and  UN/EDIFACT  Standards 


Differences  Between  ASC  X12  Standards 
and  UN/EDIFACT  Standards 


This  appendix  supports  Chapter  2  and  provides  a  more  detailed  technical 
comparison  of  the  structural  differences  between  American  National  Standards 
Institute  (ANSI)  Accredited  Standards  Committee  (ASC)  X12  and  United  Nations 
Electronic  Data  Interchange  for  Administration,  Commerce,  and  Transport 
(UN/EDIFACT). 

We  made  no  effort  to  include  aU  possible  differences  between  ASC  X12  and 
UN/EDIFACT.  We  did,  however,  make  an  attempt  to  present  those  differences 
felt  to  be  significant  and  at  the  same  time,  to  provide  the  reader  with  a  sampling 
of  the  techniques  used  to  develop  standards. 


Structural  Differences 

Data  Elements 


As  stated  in  Chapter  3,  data  elements  are  the  fundamental  building  blocks  of 
both  ASC  X12  and  UN/EDIFACT  standards.  They  perform  much  the  same  func¬ 
tion  in  both  standards  with  the  main  difference  being  in  terminology  rather  than 
functionality. 

♦  ASCX12  standzuds  have  three  types  of  data  elements: 

►  A  simple  data  element  cem  be  one  of  three  types: 

♦  One  that  requires  no  qualification 

♦  One  that  requires  qualification  and  is  referred  to  as  a  qualified  data 
element 

♦  One  that  provides  another  data  element  with  a  more  precise 
meaning  —  a  qualifier. 

►  A  component  data  element  is  a  simple  data  element  that  is  used  within 
a  composite  data  element. 

►  A  composite  data  element  is  a  group  of  two  or  more  component  (or 
simple)  data  elements  linked  together  to  form  a  single  data  element. 


B-3 


♦  UN /EDIFACT  standards  have  the  following  types  of  data  elements: 

►  A  simple  data  element  can  be  one  of  three  categories: 

♦  When  it  defines  a  precise  business  function,  it  is  termed  a  specific 
simple  data  element  (e.g.,  data  element  5284  —  Unit  Price  Basis). 

♦  When  it  defines  a  global  business  function  that  could  be  used 
across  the  widest  range-of-industry  area,  it  is  termed  a  generic  sim¬ 
ple  data  element  (e.g.,  data  element  6064  —  Quantity  Difference). 

♦  When  it  gives  a  generic  simple  data  element  a  precise  business 
function,  it  is  termed  a  data  element  qualifier  (e.g.,  data  element 
6063  —  Quantity  Qualifier) 

►  A  simple  data  element  has  the  following  characteristics: 

♦  Reference  number  in  the  EDIFACT  directory 

♦  Name 

♦  Representation 

♦  Semantic  definition. 

►  UN  /EDIFACT  also  has  component  and  composite  data  elements.^ 

Table  B-1  illustrates  a  data  element  listing  from  ASC  X12  stzindeirds.  The 
listing  shows  the  number  of  the  data  element  (16),  its  name  (Charge  Method  of 
Pa)mient),  the  data  element  t5rpe  (ID,  which  indicates  that  an  alphanumeric  code 
list  is  associated  with  die  data  element),  the  minimum  and  maximum  size  of  the 
tiUowable  data  field  (in  this  case  1),  a  definition  of  the  data  element  (Code  defin¬ 
ing  method  of  pajonent),  the  code  list  (with  Codes  A,  B,  C,  D,  E,  and  P  shown), 
and  the  definition  and  exlanation  of  each  code  (e.g.,  the  definition  of  Code  A  is 
Prepaid  Qish).^ 

Table  B-2  illustrates  a  simple  data  element  listing  from  the  UN/EDIFACT 
standards.  The  listing  shows  the  ntimber  of  the  data  element  (2380),  its  name 
(Date/Time/Period),  die  data  element  type  (an,  which  indicates  that  the  data  ele¬ 
ment  win  contain  an  alphanumeric  data  stream),  the  maximum  size  of  the  allow¬ 
able  data  field  (in  this  case,  35),  the  minimum  size  (always  1),  and  a  definition  of 
the  data  element.® 


’  EDCD  (EDIFACT  Composite  Data  Elements  Directory),  which  is  part  of  the  United 
Nations  Trade  Data  Interchange  Directory  (UNTDID). 

^ASC  X12  Standards,  Draft  Version  3  (003030),  Data  Interchange  Standards  Associa¬ 
tion,  Inc.,  ASC  X12Sf 92-707,  December  1992. 

®EDED  (EDIFACT  Data  Elements  Directory),  part  of  International  Standards  Organi¬ 
zation  7372,  which  is  part  of  the  UNTDID. 
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Table  B-1. 

ASC  X12  Data  Element  Listing 


16  Charge  Method  of  Payment 

TYPE  =  ID  MIN  =  1  MAX  =  1 

Code  defining  method  of  payment 

Code  Definition  and  Exolanation 

A 

Prepaid  Cash 

B 

Prepaid  Credit 

C 

Collect  Cash 

D 

Collect  Credit 

E 

Collect 

P 

Prepaid 

Table  B-2. 

UN/EDIEACr  Simple  Data  Element  Listing 


2380  Date/Time/Period  an..35 

The  value  of  a  date,  a  date  and  time,  a  time  or  of  a  period  in  a  specified 
representation. 


Table  B-3  illustrates  a  UN/EDIFACr  composite  data  element  listing  from 
standards.  The  listing  shows  the  ntimber  of  the  data  element  (C507),  its  luime 
(Date/Time/Period),  the  definition  of  the  composite  data  element,  the  number  of 
each  of  the  data  elements  that  make  up  the  composite  data  element  (2005,  2380, 
and  2379),  the  definition  of  each  included  data  element,  the  maximum  size  of  the 
allowable  data  field  (in  this  case  3,  35,  and  3,  respectively),  a  minimum  size  of  1 
is  implied,  and  the  requirement  designator  indicating  that  when  the  composite 
data  element  is  used,  eJl  three  elements  must  be  present  (as  indicated  by  the  des¬ 
ignation  "M",  which  means  mandatory).  A  composite  segment  listing  for  ASC 
X12  would  look  essentially  the  same. 

The  number  of  data  element  types  is  limited.  These  t3rpes  are  defined  by  the 
nature  of  the  data  carried  in  the  data  element.  For  example,  if  a  data  element  is 
an  "ID"  type,  it  means  that  it  is  an  identifier.  Identifier  data  elements  are  associ¬ 
ated  with  code  values.  Table  B-4  is  a  listing  of  the  data  element  t5rpes  found  in 
ASC  X12  and  UN/EDIFACT.'* 


^ASC  X12  Standards,  Draft  Version  3  Release  3  (003030),  Data  Interchange  Standards 
Association,  Inc.,  ASC  X12S/ 92-707,  December  1992. 
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Table  B*3. 

W^DIFACT  Composite  Data  Element  Listing 


C507 

Date/Time/Period 

Date  and/or  time  relevant  to  the  specified  date/time  type 

2005 

Date/time/period  qualifier 

M 

an..3 

2380 

Date/time/period 

M 

an..35 

2379 

Date/time/period  format  qualifier 

M 

an..3 

Table 

ASC  X12  and  UN/EDIFACT Data  Element  Types 


Type 

ASC  X12 

UN/EDIFACT 

Numeric 

Nn  (n  indicates  decimal  positions) 

n 

Decimal  number 

R 

Identifier 

ID 

string 

AN 

an 

Date 

DT  (YYMMDD) 

Time 

TM  (HHMMSSd..d) 

Binary 

B 

Fixed-length  string 

FS 

Under  ASC  X12,  relational  conditions  between  two  or  more  data  elements 
are  defined  in  a  S5mtax  note  that  begins  with  a  letter  followed  by  the  last  two 
digits  of  the  reference  designator  of  the  affected  data  elements.  The  expression 
P010203  is  an  example  of  a  relatioial  condition.  In  that  example,  the  syntax  de¬ 
mands  that  if  data  element  01  is  present,  then  data  elements  02  and  03  must  also 
be  present.  An  "R"  condition  code  might  be  expressed  as  R0203.  That  condition 
is  defined  as  follows:  either  the  second  or  the  third  data  element  in  the  segment 
must  be  present.  (Both  may  be  present)  Table  B-5  lists  the  ASC  X12  relational 
condition  codes  and  their  descriptions. 
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Table  B-5. 

ASCX12  Relational  Conditions 


Type 

Description 

P  (Paired) 

If  any  specified  data  element  is  present,  all  of  the  specified  elements  must 
be  present 

R  (Required) 

At  least  one  of  the  specified  data  elements  must  be  present. 

E  (Exclusion) 

Not  more  than  one  of  the  specified  data  elements  may  be  present. 

C  (Conditional) 

If  the  first  specified  data  element  is  present,  all  other  specified  data  ele¬ 
ments  must  be  present.  However,  any  or  all  of  the  data  elements  not  speci¬ 
fied  as  the  first  in  the  condition  may  appear  when  the  first  is  not  present. 

L  (List  conditional) 

If  the  first  specified  data  element  is  present,  at  least  one  of  the  remaining 
specified  data  elements  must  be  present.  However,  any  or  all  of  the  data 
elements  not  specified  as  the  first  in  the  condition  may  appear  when  the 
first  is  not  present. 

Segments 


A  segment  in  either  standard  is  a  construction  of  related  data  elements  and 
composite  data  elements.  UN/EDIFACT  uses  these  terms  when  defining  service 
segments. 

♦  Envelopes 

►  Interchange 

►  Functional  group 

►  Message 

♦  Delimiter  string  advice 

♦  Section  separator. 

Segments  can  be  foimd  at  all  levels  of  an  interchange.  For  example,  some 
segments  are  used  in  the  enveloping  portion  of  a  transmission.  In  other  words, 
the  segments  are  carrying  data  related  to  the  interchange  and  not  the  related 
business  information  per  se.  Other  segments  eue  designed  to  carry  specific,  re¬ 
lated  data  that  are  part  of  the  business  information  being  transmitted. 

Table  B-6  provides  a  comparison  of  ASC  X12  and  UN/EDIFACT  inter¬ 
change  codes.  The  listing  in  that  table  is  for  the  interchange  level,  functional 
group,  and  transaction  set  (ASC  X12)  or  message  (UN/EDIFACT). 
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Table  B-6. 

ASCX12  and  EDIT  ACT  Interchange  Codes 


Code 

Standard 

ASC  X12 

UN/EDIFACT 

Interchange 

-  Interchange  header 

iSA 

UNB 

-  Interchange  trailer 

lEA 

UNZ 

-  Service  string  advice 

No  equivalent 

UNA 

Functional  group 

-  Functional  group  header 

GS 

UNG 

-  Functional  group  trailer 

GE 

UNE 

Transaction  set/message 

-  Transaction  set/message 

ST 

UNH 

-  Beginning  segmenf 

BGM 

-  Transaction  set/message  trailer 

SE 

UNT 

•Uses  a  beginning  segment  but  it  tends  to  be  transaction-set  specific. 


A  segment  has  the  following  dwacteristics: 

♦  Segment  tag  (reference  ID) 

♦  Related  simple  data  elements 

♦  Related  composite  data  elements. 

A  segment  group  is  an  assembly  of  the  following; 

♦  Trigger  segment  (first  segment  in  the  group) 

♦  Related  segments 

♦  Related  segment  groups. 

In  a  segment,  each  simple  or  composite  data  element  is  further  characterized 
by  a  reference  designator  and  a  data  element  reference  number.  Data  elements 
may  have  additional  attributes,  including  a  condition  designator  and  a  semantic 
note  designator.  Four  t3rpes  of  data  element  conditions  exist  in  ASC  X12  S5mtax: 

♦  Mandatory 

♦  Optional 

♦  Floating 
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♦  Relational  (conditional). 

UN/EDIFACT  uses  only  the  mandatory  and  conditional  designations. 

The  ASC  X12  and  the  UN/EDIFACT  have  slightly  different  ways  of  portray¬ 
ing  segments.  Table  B-7  shows  an  ASC  X12  segment  listing  example®  and 
Table  B-8  shows  one  for  UN/EDIFACT.® 

Table  B-7 

Example  of  ASCX12  Segment  Listing 


N1  Name 


To  identify  a  party  by  type  of  organization,  name,  and  code 


BEE 

ELEMENT  ID 

NAME 

ATTRIBUTES 

01 

98 

Entity  Identifier  Code 

M 

ID 

2/2 

02 

93 

Name 

X 

AN 

1/35 

03 

66 

Identification  Code  Qualifier 

X 

ID 

1/2 

04 

67 

Identification  Code 

X 

AN 

2/17 

05 

706 

Entity  Relationship  Code 

o 

ID 

2/2 

06 

98 

Entity  Identifier  Code 

o 

ID 

2/2 

SYNTAX  NOTES 

02  R0203  -  At  least  one  of  N102  or  N103  is  required. 

03  P0304  -  If  either  N103  or  N1 04  is  present,  the  other  is  required. 

COMMENTS 

04  This  segment,  used  alone,  provides  the  most  efficient  method  of  providing 

organizational  identification.  To  obtain  this  efficiency  the  ‘ID  Code*  (N104)  must 
provide  a  key  to  the  table  maintained  by  the  transaction  processing  party. 

05  N105and  N106  further  define  the  type  of  entity  in  N101. 


Regardless  of  how  segments  look  in  ASC  X12  or  UN/EDIFACT  listings,  they 
both  have  essentially  the  same  characteristics.  Both  are  listings  of  included  data 
elements  edong  with  tiie  attributes  of  use  for  the  data  elements  (i.e.,  mandatory, 
optional,  etc.).  Table  B-9  presents  a  listing  of  ASC  X12  segment  attributes. 


®  ASC  X12  Standards,  Draft  Version  3  Release  3  (003030),  Data  Interchange  Standards 
Association,  Inc.,  ASC  X12S/ 92-707,  December  1992. 

‘  EDSD  (EDIFACT  Segments  Directory),  which  is  part  of  the  UNTDID. 
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Table  B-8. 

Example  of  UN/EDIFACT  Segment  with  a  Composite  Data  Element 


INP 

PARTIES  TO  INSTRUCTIONS 

Function: 

To  specify  parties  to  an  instruction  and  where  relevant,  the  instruction. 

C849 

PARTIES  TO  INSTRUCTIONS 

M 

3301 

Party  enacting  instruction  identification 

M 

an..17 

3285 

Recipient  of  the  instruction  identification 

M 

an..17 

C522 

INSTRUCTION 

C4403 

Instruction  qualifier 

M 

an..3 

4401 

Instruction,  coded 

c 

an..3 

1131 

Code  list  qualifier 

c 

an..3 

3055 

Code  list  responsible  agency,  coded 

c 

an..3 

C850 

STATUS  OF  INSTRUCTION 

C4405 

Status,  coded 

M 

an..3 

3036 

Party  name 

C 

an..35 

Table  B-9. 

ASCX12  Segment  Attributes 


Designator 

Requirement 

(M)  Mandatory 

This  data  segment  shall  be  included  in  the  transaction  set. 

(0)  Optional 

The  presence  of  this  data  segment  is  at  the  option  of  the  sending 
party. 

(F)  Floating 

Used  only  for  the  NTE  segment  that  may  appear  anywhere  in  the 
transaction  set  between  the  transaction  set  header  and  the 
transaction  set  trailer. 

(X)  Relational  (conditional) 

Used  only  when  a  stated  condition  exists. 

Semantic  and  Syntax  Notes 

In  ASC  X12,  a  semantic  note  provides  information  to  the  intended  user  of  a 
segment  within  the  context  of  a  particular  transaction  set.  Semantic  notes  pro¬ 
vide  information  regarding  the  intended  meaning  of  a  designated  data  element 
and  also  define  relational  conditions  among  data  elements  in  a  segment  based  on 
presence  of  a  specific  value  in  one  of  the  data  elements.  Syntax  notes  define 
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dependencies  based  on  the  presence  or  absence  of  other  data  elements  in  the  seg¬ 
ment. 

Table  B-10  is  a  comparison  of  the  numbers  of  segments  in  ASC  X12  and 
UN/EDIFACT.  Again,  no  inference  should  be  drawn  from  these  numbers  since 
each  standcurds  is  operated  from  a  different  design  philosophy. 


Table  B-10. 

Numbers  of  ASC  X12  and  UN/EDIFACT 
Segments 


Standard  type 

ASC  X12  UN/EDIFACT 

Segments 

Beginning  segments 

>  700  >  80 

60  1 

Notes:  Briefing  entitled  EDIFACT:  The  Next  Generation  of  EDI  Messages, 
Klaus-Dieter  Naujok,  October  1993.  Numbers  are  estimates. 


At  this  point,  we  can  summarize  some  of  the  more  significant  differences  be¬ 
tween  ASC  X12  and  UN/EDIFACT.  Table  B-11  provides  the  list  of  differences. 

Table  B-11. 

Selected  ASC  X12  and  UN/EDIFACT  Differences 


ASC  X12 

UN/EDIFACT 

One  message  for  many  uses 

One  message  —  one  purpose 

Long  multi-entity  segments 

Short,  single-entity  segments 

700  +.  segments 

80  +  segments 

1  composite 

100  composites 

1,100  data  elements 

310  data  elements 

60  beginning  segments 

1  beginning  segment 

100  +  date/time  data  elements 

1  date/time  composite 

Long  segments  (i.e.,  some  contain  34  data 
elements) 

Minisegments 
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Repetition  of  Data 

Both  ASC  X12  transaction  sets  and  UN/EDIFACT  messages  provide  similar 
ways  to  convey  multiple  occurrences  of  specific  sets  of  data  (e.g.,  items  to  requi¬ 
sition  and  receive,  wilh  multiple  dates): 

♦  Maximum  use  of  a  single  segment 

♦  Loop  of  a  group  of  segments 

♦  Nesting  loops  within  loops 

♦  Hierarchical  loops  (not  in  UN/EDIFACT). 

A  loop  in  ASC  X12  is  defined  as  a  group  of  segments  that  may  be  repeated. 
The  name  of  the  loop  is  identified  by  the  segment  identifier  (SEG.ID)  of  the  first 
segment  in  it.  The  number  of  times  the  loop  may  be  repeated  appears  in  the 
LOOP  REPEAT  column  after  the  first  segment  of  the  loop.  The  first  segment  of  a 
loop  may  only  have  a  maximum  use  of  one.  The  maximum  use  of  all  other  seg¬ 
ments  in  the  loop  may  vary  by  need. 

Loops  may  have  subordinate  loops  nested  within  them.  Those  nested  loops 
are  identified  by  an  additional  first  SEG.ID,  loop  repeats,  and  lines  drawn  inside 
the  previous  line.  Nesting  may  occur  in  an  indefinite  number  of  levels  although 
four  or  five  levels  of  nesting  is  a  more  common  maximum  seen  in  existing  stan¬ 
dards. 


Transaction  Sets  and  Messages,  Including  Their 
Enveloping  Structures 

ASC  X12  Transachon  Sets 

In  ASC  X12,  a  transaction  set  is  uniquely  identified  by  a  three-digit  number 
and  a  name;  e.g.,  810  Invoice  or  850  Purchase  Order.  In  order  to  transmit  different 
types  of  transaction  sets  firom  one  party  to  the  other,  a  hierarchical  structure  of 
headers  and  trailers  allows  the  data  to  be  segregated  logically  for  interpretation 
by  the  receiver. 

Transaction  sets  begin  with  an  ST  segment  md  end  with  an  SE  segment 
Segments  appearing  between  the  SE  and  ST  segments  are  uniquely  identified  by 
a  2-  or  3-character  segment  identifier  and  a  name.  Transaction  sets  of  the  same 
functional  group  are  transmitted  by  beginning  such  a  group  with  a  GS  segment 
and  ending  the  group  with  a  GE  segment  One  or  more  functional  groups  are 
bound  together  for  transmission  within  an  interchange  envelope  made  up  of  an 
ISA  segment  and  an  lEA  segment  Envelopes  provide  the  following: 

♦  Verification  of  proper  transmission 
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♦  Time  and  date  stamping  of  transmission 

♦  Routing  information 

♦  Version  control  information. 


UN/EDIFACT  Messages  and  Envelopes 

The  first  and  last  segments  in  the  UN/EDIFACT  message  [i.e.,  the  UNH 
(transaction  set/message)  and  UNT  (transaction  set/message  trailer)  segments] 
are  mandatory  service  segments,  defined  in  the  UN/EDIFACT  syntax  rules  (ISO 
9735).  UNH  defines  —  among  other  things  —  the  message  type,  version,  and  re¬ 
lease  number.  The  remaining  segments  (with  tags  AAA  to  FFF)  are  user  data 
segments.  Each  message  type  has  a  unique  six-letter  code  (e.g.,  INVOIC  for  the 
commercial  invoice)  that  describes  the  function  of  the  message  type  in  general 
terms. 

A  UN/EDIFACT  message  defines  several  key  items: 

♦  The  segment  that  makes  up  a  message 

♦  The  sequential  order  of  segments/ segment  groups 

♦  The  maximum  times  a  segment/ segment  group  may  repeat 

♦  Whether  a  segment/ segment  group  is  mandatory  or  conditional. 

The  beginning  segment  in  UN/EDIFACT  (as  in  ASC  X12)  defines  such  things  as 
the  following: 

♦  Purpose,  type,  and  action 

♦  Date 

♦  Unique  identification. 

Segments  are  identified  by  a  position  number  within  each  table.  Regardless 
of  which  syntax  it  is  carried  in,  a  segment  also  has  a  requirement  designator  as¬ 
sociated  with  it  indicating  its  appearance  in  the  data  stream  of  a  transmission,  as 
shown  in  Table  B-9  using  ASC  X12  terminology.^ 


^ASC  X12  Standards,  Draft  Version  3  Release  3  (003030),  Data  Interchange  Standards 
Association,  Inc.,  ASC  X12S/ 92-707,  December  1992. 
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ASC  X12  Transaction  Set  Table  Structure 


An  ASC  X12  transaction  set  consists  of  from  one  to  three  tables  (groups  of 
segments).®  The  number  of  tables  to  include  in  a  transaction  set  is  typically  de¬ 
termined  on  the  basis  of  how  the  data  are  to  be  manipulated  by  an  application 
program. 

When  the  data  are  composed  of  header  information  applicable  to  an  entire 
transaction  set,  those  detail  data  can  and  often  do  repeat,  as  in  the  case  of  multi¬ 
ple  line  items  in  a  purchase  order.  A  transaction  set  will  typically  consist  of  three 
tables  (although  detaiil  data  can  also  repeat  in  a  one-table  transaction  set).  When 
any  of  those  tests  do  not  apply,  the  number  of  tables  can  be  decreased.  Typi¬ 
cally,  when  summary  data  are  not  called  for,  a  transaction  set  will  have  one  or 
two  tables.  Ultimately,  the  way  in  which  an  application  progreun  is  designed  to 
use  data  is  the  best  measure  of  how  a  transaction  set  should  be  designed.  Table 
B-12  illustrates  the  potential  table  structure  in  an  ASC  X12  transaction  set. 

Table  B-12. 

ASC  X12  Transaction  Set  Tables 


Table  1  -  Header 

Area  at  the  beginning  of  the  transaction  set  containing  infor¬ 
mation  pertaining  to  the  entire  transaction  set 

Table  2  -  Detail 

The  actual  body  of  the  business  transaction 

Table  3  -  Summary 

Area  at  the  end  of  the  transaction  set  containing  information 
that  addresses  the  results  of  summaries  of  information  in  the 

detail  area 

Control  Characters 

Separation  of  data  elements  within  segments  and  segments  within  transac¬ 
tion  sets  and  messages  is  essential  to  keeping  track  of  the  data  stream.  In  both 
ASC  X12  and  UN/EDIFACT,  separation  and  control  are  maintained  through  a 
series  of  control  duuracters.  The  respective  syntaxes  define  the  control  characters 
shown  in  Table  B-13.’ 


‘Ibid. 

’ASC  XI2  Standards,  Draft  Version  3  Release  3  (003030),  Data  Interchange  Standards 
Association,  Inc.,  ASC  X12S/92-707,  December  1992. 
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Table  B-13. 

ASC  X12  and  UWEDIFACT  Control  Characters 


Control  characters 

ASC  X12 

UN/EDIFACT 

Data  element  separator 

+ 

Segment  ID/tag  separator 

+ 

Component  data  element  separator 

Segment  terminator 

1 

Release  character  (tells  that  a  character  follows) 

? 

Note:  ASC  X12  not  defined. 


Transaction  sets  and  messages  are  classified  by  their  status  to  indicate  the 
degree  to  which  their  designs  have  been  reviewed.  The  designations  of  the  status 
are  as  shown  in  Table 

Table  B-14. 

Transaction  Set  and  Message  Status  Designations 


UN/EDIFACT 

Status  2 

Status  2  messages  are  approved  by  WP.4  of  the  United  Nations  as 
formal  recommendations  and  registered  as  United  Nations  Stan¬ 
dard  Messages. 

UN/EDIFACT 

Status  1 

Status  1  messages  indicate  an  implementation  stage;  they  have 
been  approved  by  WP.4  of  the  United  Nations  for  trial  use. 

UN/EDIFACT 

Status  0 

Status  0  messages  indicate  a  (message  standard)  developmental 
stage.  Draft  document  submitted  to  WP.4  for  information  only. 

ANSI  Standard 

An  ANSI  Standard  is  achieved  only  after  a  DSTU  has  successfully 
gone  through  the  ANSI  standard  approval  process. 

ASC  X12  DSTU 

A  DSTU  (draft  standard  for  trial  use)  is  the  result  of  the  ASC  X12 
approval  process.  It  is  not  an  ANSI  Standard. 

Business  FuNcnoNAiirY 

The  ASC  X12  and  the  UN/EDIFACT  have  numerous  transaction  sets  and 
messages,  respectively,  that  carry  similar  business  functionedity.  DoD  has  yet  to 
undertake  the  analysis  that  would  show  which  transaction  sets  in  ASC  X12  have 
equivalents  in  UN/EDIFACT  messages.  Table  B-15  depicts  selected  ASC  X12 
transaction  sets  in  such  areas  as  engineering  and  management,  operations,  pur¬ 
chasing  and  product  data,  manufacturing,  quality  and  safety,  finance,  transpor¬ 
tation,  and  warehousing.  Table  B-16  depicts  those  business  functions  covered  by 
UN/EDIFACT  messages. 


'“The  UN/EDIFACT  Message  Design  Guidelines. 


Table  B-15. 

Examples  of  Selected  ASC  X12  Transaction  Sets  Broken  Dozvn  by  Functional  Area 


Engineering 

and 

management 

Operations 

Purchasing 

and 

product  data 

Manufacturing 

Quality 

and 

safety 

F 

Contract/Award 

Promotion 

Announcement 

Request  for  Quote 

Order  Inquiry 

Nonconformance 

Report 

Invoice 

Technical  Information 

Health  Care  Claim 

Quote 

Order  Status  Report 

Material  Safety  Data 
Sheet 

Credit  Ad 

Purchase  Order 

Planning  Schedule 

Test  Results  Report 

Service  Ir 

P.O.  Acknowledgment 

Inventory  Inquiry 

P.O.  Change 

Product  Transfer  Information 

Expense 

P.O.  Change 
Acknowledgment 

Receiving  Report 

Payment 

Catalog 

Product  Activity  Report 

Financial 

Price  Authorization 

Production  Sequence 

Accounts 

Lease  Schedule 

Product  Transfer/Resale 

Lockbox 

Price  Change 

Delivery/Retum 

Acknowledgment 

Applicatic 

Payment 

Tax  Repc 

j 

Financial 

I 

Debit  Aut 

Cancel  P 

Control  T< 

- j 

I 

Freight  In 

Functiona 

I 

I 

I 

Note:  Based  on  functional  areas  described  by  Bud  Orlando,  TRW,  CALS/CE  Report,  Volume  5,  Number  9,  September  1992,  Knowledge  Base  International,  H( 
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I 


Finance 

Transportation 

Warehousing 

All 

¥ 

Invoice 

Air  Shipment  Information 

W/H  Shipping  Order 

Crypto  Service  Message 

Data 

Credit  Advice 

Air  Freight  Invoice 

W/H  Stock  Transfer 

Application  Advice 

port 

r  - 

Service  Invoice 

Air  Shipment  Message 

W/H  Stock  Receipt 

Text  Message 

Credit  Adjustment 

Revenue  Receipts 

Statement 

W/H  Inventory 

Adjustment 

Electronic  Form  Structure 

Expense  Statement 

Motor  Carrier  Information 

Response  to  Load 

Tender 

Item  Maintenance 

Payment  Order 

Motor  Carrier  Invoice 

File  Transfer 

Financial  Report 

Motor  Carrier  Ship  Inquiry 

Functional 

Acknowledgment 

Accounts  Analysis 

Motor  Carrier  Route  Guide 

Lockbox 

Motor  Carrier  Tariff 
Information 

1 

Application  Advice 

Ocean  Booking  Reservation 

i 

Payment  Status  Number 

Ocean  Confirmation 

Tax  Reporting 

Ocean  Booking  Cancellation 

i 

1 - 

Financial  Returns 

Ocean  Shipping  Instructions 

Debit  Authorizations 

Customs  Ocean  Manifest 

1 - 

Cancel  Payments 

Ocean  (0)  Freight  Invoice 

Control  Totals  Numbers 

O/Shipment  Inquiry 

Freight  Invoice 

O/Shipment  Status 

Functional  Group  Totals 

0/T erminal  Operations 

OA/essel  Schedule 

1 

OA/essel  Stow  Plan 

1 - L 

Customs  Ocean  Release 

. 

Ise  International,  Houston,  Texas. 
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Table  B-15. 

Examples  of  Selected  ASC  X12  Transaction  Sets  Broken  Down  by  Functional  Area  (Continued) 


Finance 

Transportation 

Warehousing 

All 

Customs  Ocean  Manifest 

O/Carrier  Interchange 

Rail  Carrier  (R/C)  Shipment 
Information 

R/C  Freight  Invoice 

R/Car  Hire  Settlements 

R/C  Waybill 

R/C  Retirement  Activity 

Railroad  Station  Activity 

Transportation  Rate 

Request 

Trans.  Rate  Docket  Log 

Trans.  Ratemaking 

Trans.  Rate  Group 

Trans.  Misc.  Rates 

Trans.  Rate  Table 

Ship/Notice  Information 

Shipment  Billing 

Shipment  Information 

Shipping  Schedule 

Table  B-16. 

Examples  of  Selected  UWEDIFACT  Messages  Broken  Doom  by  Functional  Area 


Engineering 

and 

management 

Operations 

Purchasing 

and 

product  data 

Manufacturing 

Quality  and  safety 

Finance 

None 

Job  Application  Result 

Request  for  Quote 

None 

Quality  Data 

Invoice 

Job  Information  Demand 

Quotes 

Safety  and  Hazard 

Data  Sheet 

Credit  Advice 

Job  Application  Proposal 

Purchase  Order 

Sanitary/Phytosanitary 

Certificate 

Extended  Credit  Advice 

Job  Offer  Confirmation 

P.O.  Response 

Dangerous  Goods 
Notification 

Debit  Advice 

Job  Offer  Modification 

P.O.  Change 
Request 

Dangerous  Cargo  List 

Extended  Payment  Orde 

Job  Offer 

Price  Catalog 

Payment  Order 

Patient  ID 

Remittance  Advice 

Medical  Prescription 

Multiple  Payment  Order 

Medical  Service  Request 

Chart  of  Accounts 

Medical  Service  Report 

Banking  Status 

Medical  Resource 
Usage/Cost 

— 

Trial  Balance 

Report  of  Bank  Transacl 

Direct  Balance  of  Paym€ 
Declaration 

Balance  of  Payment  Sta 

Multiple  Credit  Advice 

Current  Account 

Accounting  Entries 

Financial  Cancellation 

Financial  Statement 

Direct  Debit 

Documentary  Credit  Adv 

Note:  Based  on  functional  areas  described  by  Bud  Orlando,  TRW,  CALS/CE  Report,  Volume  5,  Number  9,  September  1992,  Knowledge  Base  International,  He 


finance 

Transportation 

Warehousing 

All 

Customs  Cargo  Report 

Commercial  Invoice 

UNCID,  Interchange  Rules 

) 

Customs  Declaration 

Syntax  Implementation  Guide 

Kiit  Advice 

Customs  Conveyance  Report 

Segments  Directory 

Customs  Response 

Composites  Directory 

/merit  Order 

Arrival  Notice 

Data  Elements  Code  Lists 

er 

Booking  Confirmation 

idvice 

Firm  Booking 

lent  Order 

Provisional  Booking 

)unts 

Instructions  Contract 

JS 

International  Forwarding 

Framework 

Shipping  Instructions 

ik  Transactions 

Container  Acceptance  Order 

e  of  Payment 

Container  Arrival  Confirmation 

lyment  Statistics 

Container  Arrival  Information 

rt  Advice 

Container  Arrival  Notice 

jnt 

Container  Arrival  Message 

itries 

Container  Departure  Confirmation 

cellation 

Container  Customs  Documents 
Expiration  Notice 

ement 

Container  Departure  Notice 

Empty  Container  Disposition 

Credit  Advice 

Container  Special  Handling 

rnational,  Houston.  Texas. 
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Table  B-16. 

Examples  of  Selected  UN/EDIFACT  Messages  Broken  Down  hy  Functional  Area  (Continued) 


Amendment  of  Documentary 
Credit  Advice 


Direct  Amendment  of 
Documentary  Credit 

Documentary  Credit  Amendmen 
Information 

Request  for  Amendment 

Documentary  Credit  Approval 

Documentary  Credit  Application 

Response  to  Amendment  of 
Documentary  Credit 


Documentary  Credit  Issuance 
Information 


-inance 

Transportation 

Warehousing 

All 

Documentary 

Container  inland  Transport  Order 
Notice 

'ment  of 

Credit 

Container  Inland  Transport  Order 

Credit  Amendment 

Container  Inland  Transport  Order 
Response 

amendment 

Container  Inland  Transport  Space 
Request 

Credit  Approval 

Container  Overland  Message 

Credit  Application 

Container  Prearrival  Notice 

Amendment  of 

Credit 

Container  Predeparture 

Credit  Issuance 

Container  Pickup  Information 

Container  Pickup  Notice 

Container  Prearrival  Message 

Container  Predeparture 

. 
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Listing  of  UN/EDIFACT  Messages 
by  Status  and  ASC  X12  Transaction  Sets 


Listing  of  UN/EDIFACT  Messages  by 
Status  and  ASC  X12  Transaction  Sets 


Table  C-1 

UN/EDIFACT  Messages  by  Status 


Tag 

Message  name 

Status 

APERAK 

Application  Error  and  Acknowledgment  Message 

0 

AUTHOR 

Authorization  Message 

0 

BALANC 

Trial  Balance 

0 

BANSTA 

Banking  Status  Message 

1 

BAPLIE 

Bayplan/Stowage  Plan  Including  Empty  Space 

2 

BAPLTE 

Bayplan/Stowage  Plan  (Total  Numbers) 

2 

BOPBNK 

Reporting  of  Bank*s  Transactions  and  Portfolio  Transaction 

0 

BOPCUS 

Reporting  of  Balance  of  Pa/ment  from  Customer  Transaction 

0 

BOPDIR 

Direct  Balance  of  Payment  Declaration 

0 

BOPINF 

Balance  of  Payment  Information  from  Customer 

0 

BOPSTA 

Exchange  of  Balance  of  Payment  Statistics 

0 

CALINF 

Call  information 

0 

CASINT 

Case  Initiation  (Request  for  Legal  Action) 

0 

CASRES 

Case  Response  (Legal  Response) 

0 

CHACCO 

Chart  of  Accounts 

!  0 

CLAREQ 

Classification  General  Request 

0 

CLASET 

Classification  Information  Set 

0 

COACOR 

Container  Acceptance  Order 

0 

COARCO 

Container  Arrival  Confirmation 

0 

COARIN 

Container  Arrival  Information 

1  0 

COARNO 

Container  Arrival  Notice 

0 

COARRI 

Container  Arrival 

0 

CODECO 

Container  Departure  Confirmation 

0 

CODENO 

Container  Customs  Documents  Expiration  Notice 

0 

CODEPA 

Container  Departure 

0 

COEDOR 

Empty  Container  Disposition  Instructions 

0 

COHAOR 

Container  Special  Handling  Order 

0 

COITON 

Container  Inland  Transport  Order  Notice 

0 

Note:  Data  from  list  developed  by  Henry  Schlieper,  IBM  Germany  Information  Systems,  provided  at  the 
September  1993  Joint  Rapporteurs'  Meeting  in  Berlin,  Germany. 
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Table  C-1. 

UN/EDIFACT Messages  by  Status  (Continued) 


Message  name 


Container  Inland  Transport  Order  _ 


Container  Inland  Transport  Order  Response  _ 


Container  Inland  Transport  Space  Request  _ 


Advice  of  a  Documentary  Collection  _ 


Request  for  a  Documentary  Collection  _ 


Commercial  Dispute  Message  _ 


Advice  on  Pending  Works  _ 


Construction  —  Direct  Payment  Valuation  _ 


Drawing  Administration  _ 


Drawing  Organization  _ 


Construction  —  Establishment  of  Contract 


Construction  —  Invitation  to  Tender  _ 


Acknowledgment/Rejection/Advice  (Part  of  future  syntax) 


Construction  —  Payment  Valuation  Message 


Construction  —  Quality  Valuation  Message 


Response  on  Pending  Works 


Construction  —  Tender 


Work  Item  Quantity  Determination 


Container  Overland  _ 


Container  Prearrival  Notice  _ 


Container  Predeparture  with  Guidelines  _ 


Container  Pick-up  Information  _ 


Container  Pick-up  Notice 


Container  Prearrival  _ 


Container  Predeparture  _ 


Container  Release  Order 


Container  Shortianded  _ 


Container  Stuffing  Confirmation 


Container  Stuffing  Order 


Credit  Advice  _ 


Extended  Credit  Service 


Multiple  Credit  Advice 


Current  Account  Message 


Customs  Cargo  Report 


Customs  Declaration 


Customs  Express  Consignment  Declaration 


CUSREP  Customs  Conveyance  Report  | 

Note:  Data  from  list  developed  by  Henry  Schlieper,  IBM  Germany  Information  Systems,  provided  at  the 
September  1993  Joint  Rapporteurs'  Meeting  in  Berlin,  Germany. 


COITSR 


COLADV 


COLREQ 


COMDIS 


CONAPW 


CONDPV 


CONDRA 


CONDRO 


CONEST 


CONITT 


CONTRL 


CONPVA 


CONQVA 


CONRPW 


CONTEN 


CONWQD 


COOVLA 


COPARN 


COPDEM 


COPINF 


COPINO 


COPRAR 


COPRDP 


COREOR 


COSHLA 


COSTCO 


COSTOR 


CREADV 


CREEXT 


CREMUL 


CURRAC 


CUSCAR 


CUSEXP 
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Table  C-1. 

UN/EDIFACT  Messages  by  Status  (Continued) 


Tag 

Message  name 

CUSRES 

Customs  Response 

DEBADV 

Debit  Advice 

DEBMUL 

Multiple  Debit  Advice 

DELFOR 

Delivery  Schedule 

DELJIT 

Just-in-Time  Delivery 

DESADV 

Despatch  Advice 

DESTIM 

Equipment  Damage/Repair  Estimate 

DIRDEB 

Direct  Debit 

DIRDEF 

UN/EDIFACT  Directory  Definition 

DOCADV 

Advice  of  a  Documentary  Credit 

DOCAMA 

Advice  of  an  Amendment  of  a  Documentary  Credit 

DOCAMD 

Direct  Amendment  of  a  Documentary  Credit 

DOCAMI 

Documentary  Credit  Amendment  Information 

DOCAMR 

Request  for  an  Amendment  of  a  Documentary  Credit 

DOCAPP 

Documentary  Credit  Application 

DOCARE 

Response  to  an  Amendment  of  a  Documentary  Credit 

DOCINF 

Documentary  Credit  Issuance  Information 

DOCISD 

Direct  Documentary  Credit  Issuance 

DCOTRD 

Direct  Transfer  of  a  Documentary  Credit 

DOCTRI 

Documentary  Credit  Transfer  Information 

DOCTRR 

Request  to  Transfer  a  Documentary  Credit 

ENTREC 

Accounting  Entries 

FINCAN 

Financial  Cancellation  Message 

FINSTA 

Financial  Statement 

FUNACK 

Functional  Acknowledgment 

GATEAC 

Gate  and  Intermodal  Ramp  Activities 

GENRAL 

General  Purpose  Message 

GESMES 

Generic  Statistical  Message 

HANMOV 

Cargo/Goods  Handling  and  Movement 

ICNOMO 

Insurance  Claims  Notification 

IFCSUM 

International  Fonvarding  and  Consolidation  Summary 

IFTCCA 

International  Fonwarding  and  Transport  Shipment  Charge  Calculation 

IFTDGN 

Dangerous  Goods  Notification 

IFTFCC 

International  Freight  Costs  and  Other  Charges 

IFTIAG 

Dangerous  Cargo  List 

IFTMAN 

Arrival  Notice 

Status 


Note:  Data  from  list  developed  by  Henry  Schlieper,  IBM  Germany  Information  Systems,  provided  at  the 
September  1993  Joint  Rapporteurs'  Meeting  in  Berlin,  Germany. 
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Table  C-1. 

UN/EDIFACT  Messages  by  Status  (Continued) 


Tag 

Message  name 

Status 

IFTMBC 

Booking  Confirmation 

2 

IFTMBF 

Firm  Booking 

2 

IFTMBP 

Provisional  Booking 

2 

IFTMFR 

International  Forwarding  and  Transport  Message  Framework 

2 

IFTMCS 

Instruction  Contract  Status 

2 

IFTMIN 

Shipping  Instructions 

2 

IFTRIN 

International  Forwarding  &  Transport  Rate  Information 

1 

IFTSAI 

international  Forwarding  &  Transport  Schedule  &  Availability  Infomiation 

1 

IFTSTA 

International  Multimodal  Status  Report 

1 

IFTSTQ 

International  Multimodal  Status  Request 

0 

INFENT 

Enterprise  Information 

0 

INSPRE 

Insurance  Premium  Message 

0 

INTERS 

Interchange  Status 

0 

INVOIC 

Commercial  Invoice 

2 

INVRPT 

Inventory  Report 

2 

ITRGRP 

In  Transit  Groupage 

0 

ITRRPT 

In  Transit  Report  Detail 

0 

JAPRES 

Job  Application  Result 

0 

JIBILL 

Joint  Interest  Billing  Message 

0 

JINFDE 

Job  Infomiation  Demand 

0 

JOBAPP 

Job  Application  Proposal 

0 

JOBCON 

Job  Offer  Confirmation 

0 

JOBMOD 

Job  Offer  Modification 

0 

JOBOFF 

Job  Offer 

0 

MEDPID 

Patient  Identification  Details 

0 

MEDPRE 

Medical  Prescription 

0 

MEDREQ 

Medical  Service  Request  Message 

0 

MEDRPT 

Medical  Service  Report 

0 

MEDRUC 

Medical  Resource  Usage/Cost 

0 

MOVINS 

Stowage  Instructions 

0 

ORDCHG 

Purchase  Order  Change  Request 

2 

ORDERS 

Purchase  Order 

2 

ORDSP 

Purchase  Order  Response 

2 

PARTIN 

Party  Infomiation  (Trading  Partner  Profile  Data) 

2 

PAXLST 

Passenger  List 

2 

PAYDUC 

Payroll  Deduction  Advice 

2 

Note:  Data  from  list  developed  by  Henry  Schlieper,  IBM  Germany  Information  Systems,  provided  at  the 
September  1993  Joint  Rapporteurs'  Meeting  in  Berlin,  Germany. 
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Table  C-1. 

UN/EDH ACT  Messages  by  Status  (Continued) 


Tag 

Message  name 

PAYEXT 

Extended  Payment  Order 

PAYMUL 

Multiple  Payment  Order 

PAYORD 

Payment  Order 

PRICAT 

Price  Catalog 

PRODEX 

Product  Exchange 

PRPAID 

Insurance  Premium  Payment 

QALITY 

Quality  Data 

QUOTES 

Quotes 

REACTR 

Equipment  Reservation,  Release,  Acceptance,  and  Termination 

RECADV 

Receiving  Advice 

RECECO 

Credit  Risk  Cover  Message 

REINAC 

Reinsurance  Account  Message 

REMADV 

Remittance  Advice 

REQDOC 

Request  for  Document 

REQOTE 

Request  for  Quote 

RESMSG 

Reservation  Message 

RESREQ 

Travel,  Tourism,  &  Leisure  Reservation  Request  (Interactive  Mes¬ 
sage) 

RESRSP 

Travel,  Tourism,  &  Leisure  Reservation  Response  (Interactive 
Message) 

SAFHAZ 

Safety  and  Hazard  Data  Sheet 

SANCRT 

Sanitary/Phytosanitary  Certificate 

SLSFCT 

Sales  Forecast 

SLSRPT 

Sales  Data  Report 

SSIMOD 

Modification  of  Identity  Details 

SSRECH 

Worker's  insurance  History 

SSREGW 

Notification  of  Registration  of  a  Worker 

STATAC 

Statement  of  Account 

SUPCOT 

Superannuation  Contributions  Advice 

SUPMAN 

Superannuation  Maintenance  Message 

SUPRES 

Supplier  Response  (Reservation  Response) 

TESTEX 

Test  Message  Explicit  Mode 

TESTIM 

Test  Message  Implicit  Mode 

VESDEP 

Vessel  Departure 

WKGRDC 

Work  Grant  Decision 

WKGRRE 

Work  Grant  Request 

Note:  Data  from  list  developed  by  Henry  Schtieper.  IBM  Germany  Information  Systems,  provided  at  the 
September  1993  Joint  Rapporteurs'  Meeting  in  Berlin,  Germany. 


C-7 


Appendix  D 


Electronic  Data  Interchange 
Terms  and  Glossary 


Electronic  Data  Interchange  Terms  and 
Glossary 


Terms 


ANSI  Standard 


Bureau 


CALS 


ccnr 


CEC 


Character  set 


Code 


=  A  document  published  by  ANSI  that  has 
been  approved  through  the  consensus 
process  of  public  annoxincement  and  re¬ 
view 

=  Office  bearers  (Chairman  &  Vice  Chair¬ 
man)  of  UN/ECE/WP.4  and  the  meeting 
of  GE.1  and  GE.2  and  the  WP.4  secretariat 

=  Continuous  Acquisition  and  Life-Cycle 
Support  (formerly  Computer-aided  Ac¬ 
quisition  and  Logistics  Support).  DoD  ini¬ 
tiative  to  develop  standards  for  electronic 
interchange  of  documents,  such  as  engi¬ 
neering  drawings  and  specifications,  from 
defense  contractors 

=  Consultative  Committee  on  International 
Telegraphy  and  Telephony.  Responsible 
for  the  establishment  of  international  tele¬ 
communications  standards 

=  Commission  of  the  Emopean  Communi¬ 
ties.  The  governing  body  of  the  Emopean 
Economic  Community 

=  A  finite  set  of  different  characters  that  is 
complete  for  a  given  purpose 

=  A  character  string  used  as  an  abbreviated 
means  of  recording  or  identifying  infor¬ 
mation,  or  to  represent  or  identify  infor¬ 
mation  using  a  specific  s5nnbolic  form  that 
can  be  recognized  by  a  computer 


D-3 


Component  data  element 


=  A  simple  data  element  that  is  a  subordi¬ 
nate  portion  of  a  composite  data  element 
and  an  interchange  identified  by  its  posi¬ 
tion  within  the  composite  data  element 

Composite  data  element  =  A  construction  of  closely  related  data 

elements 

Composite  data  element  separator  =  A  character  used  to  separate  component 

data  elements  in  a  composite  data  ele¬ 
ment 

Conditional  =  A  statement  in  a  segment  or  message  di¬ 

rectory  of  a  condition  for  the  use  of  a  seg¬ 
ment,  data  element,  composite,  or 
component  data  element 

Conformance  analysis  “  Evaluation  by  an  EDIFACT  Board  of  a 

message  type  not  intended  for  develop¬ 
ment  as  a  UNSM,  to  establish  its  confor¬ 
mance  to  syntax,  directories,  and 
guidelines 

Data  element  =  The  smallest  meaningful  piece  of  informa¬ 

tion  in  a  business  transaction.  It  con¬ 
denses  information  into  short  code. 
Equivalent  to  a  field  in  a  paper  document. 
Used  to  buUd  data  segments. 

Data  element  attribute  =  A  defined  characteristic  of  a  data  element 

Data  element  directory  =  A  listing  of  identified,  named,  and  de¬ 

scribed  data  element  attributes,  with 
specifications  as  to  how  the  corresponding 
data  element  values  shall  be  represented 


Data  element  name 
Data  element  representation 
Data  element  tag 
Data  element  value 


=  Language  description  identifying  a  data 
element  concept 

=  The  format  (e.g.,  numeric,  alphabetic, 
variable  length,  etc.)  of  a  data  item 

=  A  unique  identifier  for  a  data  element  in  a 
directory 

=  The  specific  entry  of  an  identified  data 
element  represented  as  specified  in  the  di¬ 
rectory 


D-4 


Data  segment 


Delimiter 


DISA 


DRG 


DSTU 


EB 


EC 


ECE 

EDI 


EFTA 


=  Equivalent  to  a  record  in  a  paper  docu¬ 
ment  and  composed  of  a  series  of  data  ele¬ 
ments 

=  A  character  used  for  syntactical  separation 
of  data 

=  Data  Interchange  Standeirds  Association, 
Inc.  A  nonprofit  organization  funded  by 
ASC  X12  members  that  serves  as  secre¬ 
tariat  for  X12  and  the  Pan  American  EDI- 
FACT  Board.  Not  to  be  confused  with  the 
Defense  Information  Systems  Agency 

=  Directory  Reference  Group.  The  UN 
group  that  approves  aU  changes  to  UNT- 
DID  Directories 

=  Draft  standard  for  trial  use.  AnASCX12 
approved  standeud  for  use  prior  to  ap¬ 
proval  by  ANSI 

=  The  EDIF ACT  Board.  Advisory  and  sup¬ 
port  tezim  for  the  UN/EDIFACT  Rap¬ 
porteurs  of  Pan  America,  Western  Europe, 
Eastern  Europe,  Australia/ New  Zealand, 
and  Japan/Singapore,  and  Africa 

=  European  Community.  The  12  member 
states  of  the  European  Economic  Commu¬ 
nity 

=  Economic  Commission  for  Europe.  A 
United  Nations  Regional  Commission 

=  Electronic  data  interchange.  The 

computer-to-computer  exchange  of  busi¬ 
ness  information  in  a  standard  format 

=  European  Free  Trade  Association.  Com¬ 
prises  Austria,  Finland,  Iceland,  Norway, 
Sweden,  and  Switzerland 


D-5 


Electronic  commerce 


Enveloping 

Flat  file 

Formal  trial 

Framework 

Functional  acknowledgment 

Functional  group 

Functional  requirement 

Generic  data  element 
GE.1 

GE.2 


=  The  integration  of  EDI,  electronic 
mail/bulletin  boards,  electronic  funds 
transfer,  and  internal  automated  process¬ 
ing  into  a  comprehensive  system  support¬ 
ing  business  transactions  such  as 
procurement,  administration,  finance, 
supply  management,  and  transportation 

=  A  function  of  EDI  management  software 
that  groups  documents  of  the  same  type 
(transaction  set)  and  destination  into  an 
electronic  envelope 

=  A  computer  file  used  for  transferring  in¬ 
formation  firom  one  program  to  another 

=  A  (Status  1)  phase  in  UNSM  development, 
agreed  to  by  WP.4,  before  a  draft  UNSM 
reaches  the  status  of  recommendation 
(Status  2) 

=  A  template  containing  a  sequenced  set  of 
all  groups/segments  that  relate  to  a  func- 
tio:^  business  area  emd  applying  to  all 
messages  defined  for  that  area 

=  A  function  of  EDI  management  software 
that  sends  a  message  from  the  receiver  to 
the  sender  indicating  receipt  and  interpre¬ 
tation 

=  One  or  more  messages  of  the  same  type 
containing  header  and  tr2dler  segments 

=  Identification  of  the  business  or  adminis¬ 
trative  needs  to  be  met 

=  A  qualified  data  element 

=  Experts  on  data  elements  and  automatic 
data  interchange  meeting  in  the  frame¬ 
work  of  WP.4 

=  Experts  on  procedures  and  documenta¬ 
tion  meeting  in  the  framework  of  WP.4 
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GOSIP 

Identifier 

IGP 

Implemention  convention 

Implicit  representation 

Interchange 

Interchange  agreement 

Interface  program 

ISO  2382 
ISO  7372 

ISO  9735 


=  Government  Open  Systems  Interconnec¬ 
tion  Profile.  The  U.S.  Government's  adop¬ 
tion  of  OSI 

=  A  character  or  group  of  characters  used  to 
identify  or  name  an  item  of  data 

=  Intelligent  gateway  processor.  Critical 
part  of  DoD's  electronic  infrastructure  for 
electronic  commerce 

=  A  document  providing  guidance  on  how 
to  implement  an  ASC  X12  standard  of  a 
particular  activity.  DoD  transaction  set 
conventions  include  the  instructions  for 
implementing  the  control  structure  and 
definitions  of  the  usage  indicators  and  ap¬ 
plicable  codes 

=  The  technique  whereby  the  location  of  a 
data  segment  is  implied  from  its  relative 
position  within  the  message 

=  Communication  between  partners  in  the 
form  of  a  structiired  set  of  messages  and 
service  segments  containing  an  inter¬ 
change  control  header  and  trailer 

=  A  document  (usucdly  in  the  form  of  a  user 
manual)  that  describes  levels  of  syntax 
and  messages  and  legal  and  security  re¬ 
quirements 

=  A  software  program  that  defines  the  for¬ 
mat  for  passing  flat  files  between  an  appli¬ 
cation  system  and  translation  software 

=  ISO  Data  Processing  Vocabuleuy 

=  ISO  Trade  Data  Elements  Directory.  (Identi¬ 
cal  to  sections  1, 2, 3, 4,  and  9  of  the  UNT- 
DED) 

=  ISO-issued  international  standard  that  re¬ 
produces  the  UN/EDIFACT  Application 
Level  S5mtax  Rules  as  agreed  by  WP.4 
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JRT 

=  Joint  Rapporteurs'  Team.  Joint  meeting 
of  all  rapporteur  and  advisory  support 
teams 

JTC/EDI 

=  Joint  Technical  Committee  on  Electronic 
Data  Interchange  (of  Canada).  Recently 
reconstituted  as  the  Canadian  Electronic 
Data  Interchange  Standards 

Level 

=  Relative  hierarchical  position  of  a  data 
segment  within  a  message 

Mandatory 

=  A  statement  in  a  segment  or  message  di¬ 
rectory  that  specifies  that  a  segment,  a 
data  element,  a  composite  data  element, 
or  a  component  data  element  must  be 
used 

Mapping 

=  The  process  of  diagrammmg  what  EDI 
data  are  to  be  exchanged,  how  the  data 
are  to  be  used,  and  what  application  sys¬ 
tems  require  the  data 

Maximum  use 

=  Specifies  the  maximum  number  of  occur¬ 
rences  allowed  for  a  segment  or  a  loop 
that  may  be  repeated 

MDl 

=  Trade  —  a  message  development  group 

MD2 

=  Transport:  Rail/Road,  Sea  and  Air  —  a 
message  development  group 

MD3 

=  Customs  and  other  Official 

Procedures  —  a  message  development 
group 

MD4 

=  Finance:  Banking  and  Insurance  —  a 
message  development  group 

MD5 

=  Construction  —  a  message  development 
group 

MD6 

=  Statistics  —  a  message  development 
group 

MD7 

=  Insurance  —  a  message  development 
group 
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MD8 

Message 


Message  code 
Message  diagram 
Message  t5q5e 


Nested  segment 


NSB 


ODETTE 


Omission 


OSI 


PAEB 


=  Tourism  —  a  message  development  group 

=  A  set  of  segments  in  the  order  specified  in 
a  message  directory  starting  with  the  mes¬ 
sage  header  and  ending  with  the  message 
trailer  (Source:  ISO  9735)  (equivalent  to 
transaction  data  set) 

=  A  unique  six-character  alphabetic  refer¬ 
ence  identifying  a  message  type 

=  A  graphic  representation  of  the  sequence 
of  segments  within  a  message 

=  An  identified  and  structured  set  of  data 
elements  covering  the  requirements  for  a 
specified  type  of  transaction 

=  A  segment  that  directly  relates  to  another 
segment  in  an  identified  and  structured 
group  of  segments  covering  the  require¬ 
ments  for  a  specific  message  type 

=  National  standards  body.  An  organiza¬ 
tion  within  a  country  charged  with  devel¬ 
oping  national  standards  and  contributing 
to  international  standeudization,  i.e.,  ANSI 

=  Organization  for  Data  Exchange  Through 
Telecommunications  in  Europe.  ODETTE 
has  an  EDI  standzud  used  by  the  Euro¬ 
pean  Automotive  Industry 

=  Exclusion  in  a  message  of  one  or  more 
units  of  data  that  are  defined  as  condi¬ 
tional  in  a  message-t5rpe  specification 

=  Open  system  Interconnectivity.  Reference 
model  for  computer  interconnections  over 
electronic  networks 

=  Pan  American  EDIF ACT  Board.  Coordi¬ 
nates  UN/EDIFACr  development  and 
maintenance  with  the  other  EDI  Boeuds 
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Progressive  data  transfer 


Protocol 


Qualified  data  element 


Qualifier 


Rapporteur 


Receiving  secretariat 


Release 


Release  character 


Repeating  segment 


Requirement  designator 


=  A  technique  allowing  a  sender  to  transfer 
a  series  of  messages  as  more  data  become 
available.  The  recipient  creates  a  business 
file  for  the  eventual  linking  of  all  the  data. 
Messages  are  linked  by  common  referenc¬ 
ing. 

=  A  set  of  rules  governing  information  flow 
in  an  electronic  communication  system 

=  A  data  element  whose  precise  meaning  is 
conveyed  by  an  associated  qualifier. 
(Qualiied  data  segment  —  conveyed  by 
an  associated  qualifier) 

=  A  data  element  whose  value  shall  be  ex¬ 
pressed  as  a  code  that  gives  specific  mean¬ 
ing  to  the  function  of  another  data 
element  or  segment 

=  A  person  nominated  by  his  or  her  govern¬ 
ment  and  appointed  by  UN/ECE  WP.4  to 
initiate  and  coordinate  UN/EDIFACr  de¬ 
velopment  work  in  his  or  her  geographi¬ 
cal  area  of  jurisdiction 

=  The  RT  Secretariat  that  has  received  a  new 
message  request,  change  request,  or  code 
request  and  that  fulfills  secretariat  duties 
tmtil  a  supporting  secretariat  is  assigned 
by  the  working  group 

=  A  unique  subissue  of  a  directory  set 
within  a  version.  Releases  define  version 
publications  (usually  two  per  year). 

=  A  character  used  to  restore  its  original 
meaning.  Any  character  used  as  a  syntac¬ 
tical  separator 

=  A  segment  that  may  repeat  in  a  message 
as  specified  in  the  relevant  message-type 
specification 

=  Specifies  whether  an  element  or  segment 
is  mandatory  or  conditional 
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RINET 


RT 


Section  control  segment 


Segment 


Segment  code 
Segment  directory 
Segment  name 
Segment  table 
Segment  tag 


Segment  terminator 
Separator  character 
Service  data  element 


=  Reinsurance  and  Insurance  Network.  An 
international  network  set  up  by  eight 
European  reinsurance  companies 

=  Rapporteur  Advisory  and  Support  Team. 
A  tody  of  experts  organized  in  commit¬ 
tees  providing  coordinated  input  emd  sup¬ 
port  to  the  rapporteurs 

=  A  service  segment  used  to  separate 
header,  detail,  and  summary  sections  of  a 
message  where  necessary  to  avoid  ambi¬ 
guities  in  the  message  segment  content 

=  A  predefined  and  identified  set  of  func¬ 
tionally  related  data  element  values  that 
are  identified  by  their  sequential  positions 
within  the  transaction  set 

=  A  code  that  uniquely  identifies  each  seg¬ 
ment  as  specified  in  a  directory 

=  A  listing  of  identified,  named,  described, 
and  specified  segments 

=  One  or  more  words  in  a  natural  language 
identifying  a  data  segment  concept 

=  A  graphic  representation  of  the  format 
and  composition 

=  A  composite  data  element  in  which  the 
first  component  data  element  contains  a 
code  that  uniquely  identifies  a  segment  as 
specified  in  the  relevant  segment 
directory.  (Additional  component  data 
elements  can  be  conditionally  used  to  in¬ 
dicate  the  hierarchical  level  and  nesting 
relation  in  a  message  and  the  incidence  of 
repetition  of  the  segment) 

=  A  syntax  character  indicating  the  end  of  a 
segment 

=  A  character  use  for  S5mtactical  separation 
of  data.  (A  delimiter) 

=  A  data  element  used  in  service  segments 
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Service  segment 
Service  string  advice 

Simple  data  element 
Simple  segment 

Status  0 

Status  1 

Status  2 

Subset 

Summary  section 

Supporting  secretariat 

Syntax  rules 


=  A  segment  required  to  service  the  inter¬ 
change  of  user  data 

=  A  character  string  at  the  beginning  of  an 
interchange  defining  syntactically  delimit¬ 
ing  characters  and  indicators  used  in  the 
interchange 

=  A  data  element  containing  a  single  value 

=  A  segment  that  requires  no  qualification. 
The  meaning  is  fixed  and  explicit. 

=  Draft  document  (work  is  progressing  but 
has  not  reached  an  advanced  stage.  Docu¬ 
ment  issued  for  information  only).  Allo¬ 
cated  by  RT 

=  Draft  recommendation  (document  has 
been  approved  by  WP.4  for  trial  use). 
Similar  to  ASC  X12  draft  standards 

=  Recommendation  (document  has  been  ap¬ 
proved  by  WP.4  as  a  formal  recommenda¬ 
tion  and  registered).  Similar  to  ANSI 
standards 

=  An  extract  of  a  message  t3q)e  for  use 
within  one  industry  or  application.  The 
subset  usually  indicates  only  those  seg¬ 
ments,  elements,  and  code  values  needed 
by  the  industry  or  application 

=  The  portion  of  the  message  that  follows 
the  body  of  the  message  emd  that  contains 
summary  information  relating  to  the  en¬ 
tire  message 

=  The  RT  Secretariat  assigned  by  a  working 
group  to  support  the  working  group  ac¬ 
tivities  that  include  responsibility  for  sub¬ 
mission  of  all  documentation 

=  Rules  governing  the  structure  of  an  inter¬ 
change  and  its  functional  groups,  mes¬ 
sages,  segments,  and  data  elements 
(Source:  ISO  9735) 
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TD-AP 


Technical  assessment 


TEDIS 

TRADACOMS 


Trade  data  log 


Trade  data  message 


Trade  data  transfer 


Trade  Facilitation  Organization 


Trade  transaction 


=  Trade  Data  Interchange  Application  Pro¬ 
tocol.  A  method  for  interchange  of  trade 
data  messages  based  on  international 
standards  for  the  presentation  and  struc¬ 
turing  of  trade  data  transfers  conveyed  by 
teletransmission 

=  The  process  by  which  messages  and  sup¬ 
porting  directories  are  evaluated  for  con¬ 
formance  to  syntax,  design,  and  syntax 
implementation  rules 

=  Trade  Electronic  Data  Interchange  Sys¬ 
tems.  A  program  of  the  CEC  and  EFTA 

=  Trade  Data  Communications  Standards. 
The  ana's  published  manucd  for  EDI  us¬ 
ers  in  the  United  Kingdom 

=  A  collection  of  trade  data  transfers  that 
provides  a  complete  historical  record  of 
trade  data  interchanged 

=  Data  exchanged  between  pcirties  con¬ 
cerned  with  the  conclusion  or  perform¬ 
ance  of  a  trade  transaction 

=  One  or  more  trade  data  messages  seiit  to¬ 
gether  as  one  unit  of  dispatch  that  in¬ 
dudes  heading  and  terminating  data 

=  A  national  body  coordinating  or  monitor¬ 
ing  trade  facilitation  developments  at  a 
national  level 

=  A  specific  contract  for  the  purchase  and 
sale  or  supply  of  goods  and/or  services 
and/or  otiier  performance  between  tiie 
parties  concerned,  identified  as  the  trans¬ 
action  to  which  a  trade  data  message  re¬ 
fers 


TRADE/ WP.4/R....  =  A  document  issued  by  the  ECE  Secretariat 

in  conjxmction  with  the  meetings 

Trading  Partner  Agreement  =  A  document  that  sets  forth  the  rights  and 

obligations  of  the  trading  partners 
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Trading  partners 

Transaction  set 

UN/ECE 

UN/JEDI 
UN  layout  key 

UNSM 

UNTDED 

UNTDID 

User  data  segment 
VAN 

Version 


=  The  sending  and/  or  receiving  parties  in¬ 
volved  in  exchanging  electronic  business 
messages 

=  The  EDI  equivalent  of  a  paper  business 
document  primarily  comprising  data  ele¬ 
ments  and  data  segments.  Equivalent  to 
the  EDIFACT  message 

=  United  Nations/Economic  Commission 
for  Europe.  One  of  five  regional  UN  com¬ 
missions  comprising  North  America, 
Western  Europe,  and  Eastern  Europe 

=  United  Natioirs  Joint  EDI.  An  ad  hoc 
group  of  WP.4  formed  in  1986 

=  A  pro-forma  document  used  for  indicat¬ 
ing  spaces  reserved  for  certain  statements 
appearing  in  international  trade  docu¬ 
ments  in  an  integrated  system 

=  United  Nations  Standard  Message.  A 
standard  EDIFACT  message  that  has  been 
registered  with  the  UN/ECE  WP.4  and  is 
to  be  used  in  electronic  data  interchange 
between  business  partners 

=  United  Nations  Trade  Data  Elements  Direc¬ 
tory,  a  part  of  which  constitutes  ISO  7372 
and  defines  standard  data  elements  and 
cissociated  codes.  UNTDED  is  jointly 
maintained  by  UN /ECE  and  ISO 

=  United  Nations  Trade  Data  Interchange  Di¬ 
rectory.  It  includes  the  UN/EDIFACT: 

ISO  9735,  MDG,SIG,EDED,EDCL, 
EDCD,  EDSD,  and  EDMD.  It  also  in¬ 
cludes  theUNCID 

=  A  segment  containing  application  data 

=  Value-added  network.  A  service  provider 
that  transmits,  receives,  and  stores  EDI 
messages  for  trading  partners,  as  well  as 
other  EDI-related  functions 

=  An  issue  of  a  directory  set 
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Version  number 

=  A  number  identifying  a  version  issue. 
Used  in  Data  Element  0052  in  EDEFACT 
interchanges  to  identify  the  correct  direc¬ 
tory  set  base  for  the  interchange  messages 

Version/  release 

=  The  periodic  issue  of  EDEFACT  directory 
sets 

WP.4 

=  Working  Party  4  on  Facilitation  of  Inter- 
natioiral  Trade  Procedures 
(UN/ECE/WP.4).  Responsible  for  vari¬ 
ous  EDI  initiatives 

X.400 

=  CCITT's  message  handling  specification, 
initially  for  electronic  meiil  interchange 
and  recently  EDI 

X.500 

=  CCITT  standard  for  electronic  directory  of 
electronic  mail  addresses 

Glossary 

AIAG 

=  Automotive  Industry  Action  Group 

ANA 

=  Article  Numljer  Association 

ANEB 

=  Australia/New  Zealand  EDEFACT  Board 

ANSI 

=  American  National  Standeirds  Institute 

ASCX12 

=  Accredited  Standards  Committee  X12 

ASYCUDA 

=  Automated  System  for  Customs  Data 

AUSTRIAPRO 

=  Austrian  trade  facilities  organization 

AWG 

=  Awareness  Group  (under  the  Western 
European  EDEFACT  Board) 

BMG 

=  JRT  Business  Modeling  Group 

CALS 

=  Continuous  Acquisition  and  Life-Cycle 
Support  (formerly  Computer-aided  Ac¬ 
quisition  and  Logistics  Support) 

CCC 

=  Customs  Cooperation  Council 
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ccm 

CCL 

CEBIS 

CEC 

CEFIC 

CEN 

OM 

CIT 

CRP 

DAASO 

DCE 

DFAS 

DFAS  -  CO 

DISA 

DLA 

DLMSO 

DMRD 

DRG 

DSTU 

EA 


=  Consultative  Committee  on  International 
Telegraphy  and  Telephony 

=  Consolidated  Code  List 

=  The  Commissions  EDIFACT  Board  Infor¬ 
mation  System 

=  Commission  of  the  European  Communi¬ 
ties 

=  European  Chemical  Industry  Federations 

=  corporate  information  management 

=  International  Railways  Transport  Com¬ 
mittee 

=  Conference  Room  Paper 

=  Defense  Automatic  Addressing  System 
Office 

=  Defense  CALS  Executive 

=  Defense  Finance  and  Accounting  Service 

=  Defense  Finance  and  Accounting 
Service  —  Columbus 

=  Data  Interchange  Standards 
Association,  Inc. 

=  Defense  Logistics  Agency 

=  Defense  Logistics  Management  Systems 
Office 

=  Defense  Management  Report  Decision 

=  Directory  Ref  ereiice  Group 

=  draft  standard  for  trial  use 

=  Executive  Agent 
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EAN 


=  International  Article  Numbering 
Association 


EB 

EC 

ECE 

EDCD 

EDGE 

EDED 

EDI 

EDIA 

EDIFACT 

EDIFICE 

EDIFRANCE 

EDMD 

EDSD 

EEC 

EEEB 

EFTA 

ESD 


=  The  EDIFACT  Board 

=  electronic  commerce  or  European  Com¬ 
munity 

=  Economic  Commission  for  Europe 

=  EDIFACT  Composite  Data  Elements  Direc¬ 
tory  (included  in  the  UNTDID) 

=  EDIFACT  Code  List  (included  in  the 
UNTDID) 

=  EDIFACT  Data  Elements  Directory  [in¬ 
cluded  in  UNTDID  (a  subset  of  the  UNT- 
DED)] 

=  electronic  data  interchange 

=  Electronic  Data  Interchange  Association 
(formerly  TDCQ 

=  Electronic  Data  Interchange  for  Admim- 
stration,  Commerce,  and  Transport 

=  Electronic  Data  Interchange  Forum  for 
Compcunies  with  Interests  in  Computing 
and  Hectronics 

=  French  organization  supporting  EDEFACT 

=  EDIFACT  Message  Directory  (included  in 
the  UNTDID) 

=  EDIFACT  Segments  Directory  (included  in 
the  UNTDID) 

=  European  Economic  Community 
(12  nations) 

=  Eastern  Europe  EDIFACT  Board 

=  European  Free  Trade  Association 

=  EDIFACT  Standards  Development 
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ETAG 

=  EDIFACT  Technical  Assessment  Group 

FAR 

=  Federal  Acquisition  Regulation 

FIATA 

=  International  Federation  of  Freight  For¬ 
warders  Association 

FIPS 

=  Federal  Information  Processing  Standard 

FMS 

=  foreign  military  sales 

FTAM 

=  file  transfer,  access,  and  management 

GATEC 

=  government  acquisition  through  elec¬ 
tronic  commerce 

GATT 

=  General  Agreement  on  Tariffs  and  Trade 

GOSIP 

=  Government  Open  Systems  Interconnec¬ 
tion  Profile 

GTDI 

=  Guidelines  for  Trade  Data  Interchange 

lAPH 

=  International  Association  of  Ports  and 
Flarbors 

lATA 

=  International  Air  Transport  Association 

IC 

=  implementation  convention 

ICAA 

=  International  Qvil  Airports  Association 

ICAO 

=  International  avE  Aviation  Organization 

ICC 

=  International  Chamber  of  Commerce 

ICS 

=  International  Cheimber  of  Shipping 

IDEA 

=  International  Data  Exchange  Association 

me 

=  International  Electrotechnical  Commis¬ 
sion 

I-EDI 

=  JRT  Interactive  EDI  Group 

IGC 

=  JRT  Message  Implementation  Guidelines 
Group 
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IGP 

=  intelligent  gateway  processor 

IMO 

=  International  Maritime  Organization 

IPMS 

=  Inter-Personal  Messaging  Service 

IRU 

=  International  Road  Transport  Uition 

ISDN 

=  integrated  services  digital  network 

ISO 

=  International  Standards  Organization 
(based  in  Geneva) 

ISSB 

=  Information  Systems  Standards  Board 

ITU 

=  International  Telecommunications  Union 

JEC 

=  Japan  EDIFACT  Committee 

JEDI 

=  Joint  Electronic  Data  Interchange 

JRT 

=  Joint  Rapporteurs  Team 

JSEB 

=  Japan  and  Singapore  EDIFACT  Board 

jra 

=  Joint  Technical  Committee  No.  1,  Informa¬ 
tion  Technology,  of  the  ISO/IEC 

LMI 

=  Logistics  Management  Institute 

MAG 

=  Maintenance  Group  (imder  the  Western 
European  EDIFACT  Board) 

MD 

=  Message  Development 

MDG 

=  Message  Design  Guidelines 

MODELS 

=  Modernization  of  Defense  Logistics  Stan¬ 
dard  Systems 

NAEB 

=  North  American  EDIFACT  Board  (now 
the  Pan  American  EDIFACT  Board) 

NIST 

=  National  Institute  of  Standards  and  Tech¬ 
nology 

NSB 

=  National  Standards  Body 
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ODETTE 

OPM 


=  Organization  for  Data  Exchange  Through 
Telecommunications  in  Europe 

=  ASC  X12  Organization  and  Procedures  Man¬ 
ual 


OSI 

PAEB 

PDG 

PRB 

RFQ 

RINET 

RT 

SCC-JTC/EDI 

SDG 

SEC 

SIG 

SITPRO 

SJG 

SM 

SWG-EDI 

SWIFT 

TAG 


=  open  system  interconnectivity 

=  Pan  American  EDIF  ACT  Board 

=  Procedures  and  Doaimentation  Group 
(imder  the  Western  European  EDIF  ACT 
Board) 

=  Procedures  Review  Board 

=  Request  for  Quote 

=  Reinsurance  emd  Insurance  Network 

=  Rapporteur  Advisory  and  Support  Team 

=  Standards  Coimcil  of  Canada  Joint  Tech¬ 
nical  Committee  on  Electronic  Data  Inter¬ 
change 

=  UN/EDIFACT  -  ISO  Syntax  Develop¬ 
ment  Group 

=  Singapore  EDEFACT  Committee 

=  Simpler  Trade  Procedures  Board 

=  JRT  Security  Joint  Group 

=  Standard  messages 

=  Special  Working  Group  on  EDI  of  ISO 
JTCl 

=  Society  for  Worldwide  Interbank 
Financial  Telecommunications 

=  Techniced  Assessment  Group  (under  the 
Western  European  EDIF  ACT  Board) 


D-20 


TC154 

TCC 

TD-AP 

TDCC 

TEDIS 

TPA 

TRADACOMS 

UCC 

UCS 

UIC 

UIRR 

U.K. 

UN 

UNaD 

UNCURAL 

UNCTAD 

UN/ECE 

UN/EDIFACr 


=  ISO  Technical  Committee  154  for  Docu¬ 
ments  and  Data  Elements  in  Administra¬ 
tion,  Commerce,  and  Industry 

=  Technical  Coordinating  Committee 

=  Trade  Data  Interchange  Application  Pro¬ 
tocol 

=  Transportation  Data  Coordinating  Com¬ 
mittee  (now  EDIA) 

=  Trade  Electronic  Data  Interchange  Sys¬ 
tems 

=  trading  partner  agreement 

=  Trade  Data  Communications  Standards 

=  Uniform  Code  Council,  Inc. 

=  Uniform  Communication  Standard  (EDI 
standard  used  by  the  grocery  industry) 

=  International  Union  of  Railways 

=  Union  of  International  Redl/Road  Trans¬ 
port 

=  United  Kingdom 

=  United  Nations 

=  Uniform  Rules  of  Conduct  for  the  Inter¬ 
change  of  Trade  Data 

=  United  Nations  Commission  on  Interna¬ 
tional  Trade  Law 

=  United  Nations  Conference  on  Trade  and 
Development 

=  United  Nations/Economic  Commission 
for  Europe 

=  United  Nations  Electronic  Data  Inter- 
cheinge  for  Administration,  Commerce, 
and  Transport 
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UNIDO 

United  Nations  Industrial  Development 
Organization 

UN/JEDI 

= 

United  Nations  Joint  EDI 

UNSM 

= 

United  Nations  Standard  Message 

UNTDED 

= 

United  Nations  Trade  Data  Elements  Direc¬ 
tory 

UNTDID 

= 

United  Nations  Trade  Data  Interchange  Di¬ 
rectory 

VAN 

= 

value  added  network 

WEEB 

= 

Western  European  EDIFACT  Board 

WP.4 

= 

Working  Party  4 
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